Ah yes! This would a be a cool topic to work on.
I’m suggesting that the data should live within $database (insert favorite here). A website can retrieve it and so can a Thunkable app if we build one.
2 Likes
Ohhh. Making this into a Thunkable app would also be a fun thing to do but it doesn’t support collaboration.
Why not?
1 Like
I’m talking about Thunkable, not the database 
Thunkable will support Saved Screen collaboration but that’s for the Enterprise package. So, I don’t think it’s possible.
You can fake “saved screen collaboration” by one user remixing another’s project, saving the screen wanted, then importing it. Well, in snap to position anyway. I think someone said saved screens weren’t in DnD currently? (Another issue for the tracker!)
2 Likes
Oh! That might work. Me and @samclever started collaborating using Discord in May. He created a Gmail account and shared that account and the password with me. We used to work on the app together that way.
Interesting idea. The one thing I have to say about that is whoever is editing the app needs to make sure two people aren’t editing at the same time, and when you are done, you leave it in a stable state for the next person. So I like it, but it would take some collaboration. It is a bit dangerous.
1 Like
True. If we are both editing at the same time, it would edit one of our screens every time a change was made, so we wouldn’t get to work at all.
1 Like
One more thought, and I don’t know if this is possible, but what the heck. If we went with a website like Google Sites, G Sites does support embedding HTML, CSS, and JavaScript. So if we were able to make something that pulled from a database, and then pasted that code in, that might work?
2 Likes
Oh no! I’m terrible at web development, but I’d love to contribute all the same.
Proposal:
- Let’s use a Thunkable web app as our first front end. Not necessarily our /only/ front end, but I am certain that we have the expertise to do that right here in this thread, and I think we should play to our strengths first.
- And let’s put Firebase on the back end. Although it’d be nice to have the accessibility of Google Sheets, I’m worried about scalability and not having a good way to deal with non 1-to-1 relationships.
- There will be a bunch of data collection work to be done, which we can distribute to anyone who wants to help. I suggest that most of it should be links to useful things (documentation, tutorials, GitHub bugs, etc), rather than all new content, but that each component/block should have a regularly updated “status” setting (on each platform).
- We’re going to need a handful of screens to browse data, display a big status summary, add/update block status entries, etc. Individual folks interested in contributing could write a screen. Once we settle on a data model in Firebase, splitting up the work for anyone who wants to contribute shouldn’t be too bad.
- @domhnallohanlon , could you make us a forums category for discussions? All of the discussion about whether a block is broken or not could go there, and be linked from the tracker.
2 Likes
Here’s a mock-up for data structure for Firebase. (I didn’t add all items in each category, clearly!) I’m certain there’s a better way to do it, so I hope someone will come along and help improve it!
{
"entries" : {
"blocks" : {
"control" : {
"when button click" : {
"current_function" : {
"Android download" : "mostly functional",
"iOS live" : "fully functional"
},
"issues" : [ {"descriptions of each issue, with links - new addition!"} ]
"documentation" : [ {
"text" : "snap to position",
"url" : "https://docs.thunkable.com/button"
}, {
"text" : "drag and drop",
"url" : "https://docs.thunkable.com/v/drag-and-drop/button"
} ],
"image" : "https://gblobscdn.gitbook.com/assets%2F-LAn5scXl2uqUJUOqkJo%2F-MWYeR-MpHbCPfo6qGVQ%2F-MWYh5kYkBvj2NAsk5_y%2Fbtn_click_2.png?alt=media&token=f27909d1-02aa-48e7-a34f-a02514829d92",
"intro" : "A button is just something you can click on to perform an action. This action can be anything from navigating to a different screen, saving information to a database, or playing a sound.",
"workarounds" : [ {
"text" : "Text for the URL",
"url" : "http://some forums page"
}, {
"code_link" : "https://link to a project",
"long_text" : "lots of firebase hosted text about the problem"
} ]
}
},
"datasource" : {
"create row" : {
"workarounds" : [ {
"text" : "Text for the URL",
"url" : "http://some forums page"
}, {
"code_link" : "https://link to a project",
"long_text" : "lots of firebase hosted text about the problem"
} ]
}
}
},
"designer" : {
"data viewer list" : {
"workarounds" : [ {
"text" : "Text for the URL",
"url" : "http://some forums page"
}, {
"code_link" : "https://link to a project",
"long_text" : "lots of firebase hosted text about the problem"
} ]
}
}
}
}
2 Likes
Perfect! Firebase is my weak point but I can help with the search bar, and I love working with data viewers (I assume we’re using those to display data?).
We are going to display what exactly the bug is, right?
I
Well, all we can report is phenotype, not genotype (sorry, I’m a biochemist), but yes, definitely. That’d go on an individual block/component page – and yeah, when I was mocking it up, apparently I didn’t show that clearly!
2 Likes
Sure. I’m currently working on a test app to retrieve data from that JSON with a series of ‘levels’. I’m nearly done, and I can try to share the link in another 5 minutes to see if this is the base of what we want.
Cool! That JSON is actually a firebase write out. It shouldn’t be hard to take your logic and use cloud variables to get live data.
1 Like
Yeah. I’d do that but I don’t have that firebase structure (and I’m too lazy to build it out myself!) so I’ll try the JSON first.