As was announced several weeks ago, Thunkable support for the Classic is going. Not only they want to terminate it, but even in the interim, the API 28 compliant compiler, required by Google since August, is not working for sizable projects, and applications that could be compiled with the previous version (API 26) need to have most of their logic removed (to only 1/3 of the original size) just to allow compilation.
The ‘effort’ to fix that compiler has still to be completed, since 3 months later, I am still unable to issue an update to my apps. I dare assume I am not the only one so affected (and to be honest, I doubt that they even really bother fixing it…)
At some point, the writing on the wall is that Thunkable does not really care about Classic users, and we should jump ship, the obvious alternative being Kodular.
It has been announced some time ago, Kodular and AppyBuilder are merging. I did some tests to check how my .aia file was loading (some minimal adjustment required, and some initial resolution issue in one case) but essentially Kodular and AppyBuilder are very similar. The merging removes the burden of having to pick one.
Any insight that I can relay to the Thunkable forum? People come with valid issues on the Classic forum, and Thunkable staff reply by showing how it could be done in X (in a manner that I can only call ‘promotional’)
Is Kodular already API 28 compliant?
Apart from my limited testing, is there any additional collated information on the transition from Thunkable, some sort of a compendium of things that differ, what to watch for, and so on; that was put together?
Also, there is a lot of information that was accumulated in the Thunkable Classic forums. It would be sad if all that accumulated knowledge would be lost, since everyone on Thunkable will likely end up here anyway. Anything is being done to allow Q&A from the Classic forum to be migrated here?
There are a lot of differences. The basics and then i mean the App Inventor components will likely work. You have to look at the components you use. All ad components should be removed. But for instance Thunkable and Kodular both have a Google Maps component but they are not compatible. So in some cases it is better to start your app anew then to try to import it with unknown effects. I did that for the apps that are most important to me.
Much of the needed Q&A on the Thunkable and AppyBuilder forum is linked from inside are own topics. But we (will) do that less and less because the knowledge is also shared here.
I know there are differences; what I am talking about is if there is such a thing as a document that will summarize what needs to be changed for a Thunkable app to be ported, something not unlike the comparison list that you put on Google Docs.
The additional components Kodular has are less of an issue, since an app ported from Thunkable will evidently not use them.
But the kind of info like the difference in the way Google Maps is used is exactly the type of information that should be in a quick “premier guide to transition to Kodular”.
I wish that starting anew would be possible, but when you consider that apps like mine are close to the equivalent of one year full time work, there is hope that a large chunk of it should be portable.
Right now, for instance, I wanted to push a new version of one of my app, and I was waiting for Thunkable to fix that API 28 compiler; something that is not happening fast. And which I doubt will even happen, even after I passed them the complete source for one of my app that worked with the API 26, so that they had something to test their compiler with…
It took you that amount of time to make your app, but that’s for sure the first time. Because you need to test, retest, test even more, come up with solutions, workarounds, a lot of trial and error maybe.
But now you have it all working and even if you have to copy it block by block, which I’m sure will not be necessary, it will not take you that long. In fact (and this happened to me before) you will be able to revisit your app’s “guts” and optimize some redundant code that you just left as it was, because it was working.
The point is that “starting from scratch” was suggested.
Even if I have a complete framework reference to duplicate along the lines of what I have, with over 7000 blocks in only one of my app, we are talking about weeks of work here.
And the code is not really capable of being optimized more than it is now. For example, I replaced all the instances where “x=x+1” with a returning procedure call that adds 1 to the value of the argument, because that saves 1 (ONE!) block per call. That was needed at the level I am at.
For 95% of users, your ‘advice’ may apply, because most users are not aerospace engineer who have been writing aircraft performance and flight data recorder analysis software for decades. But trust me when I state that it does not apply to me. And if writing from scratch was really an option, I would change framework entirely and go with Flutter/Dart.
What I am here is a rather extreme example of pushing the envelope. If the system works for my apps, you can be damn sure it would work for everyone. And I am concerned for users who do not have facility and experience dealing with computers to my level. They will feel left out when Thunkable closes up.
You “Italo”, have an account on Thunkable. Go there and visit the forums, and check the kind of support I have been providing. You will probably feel like someone trying to give investment advise to Warren Buffet.
We all welcome you here from Thunkable, luckily you didn’t go to X, because then you’d be stuck in a contract type thing, where you can’t switch unless you don’t wanna take your project with you.
I have accounts everywhere In fact I’m a PowerUser in the MIT App Inventor 2 forum since 2015, I know what you mean. There’s other PowerUsers like Hossein and Taifun who’s been there even longer.
I’ve made some big projects, probably not as complex as yours, but they were about 5000 blocks, optimized to the maximum, and yes, I had to re make it when I switched from Thunkable to AppyBuilder.
I like pushing the envelope too, I would like to see your app when it’s available.
As I wrote as an answer to several posting by Thunkable staff trying to incite people to migrate to X, X is not a proper substitute for Classic (and by way of consequence, Kodular, AppyBuilder and anything else that is a derivative of App Inventor).
The absence of the most basic canvas operations (drawing a simple line from A to B; getting a canvas touch event at location X,Y; being able to write text; being able to extract the pixel colour value at the X,Y coordinates); the absence of a simple webview string that allows bi-directional communication to an HTML/JavaScript file among others are reason why it cannot perform what I need.
Add to this its disproportionate use of memory space, the harsh limits in the number of components and logic blocks it can handle before turning completely unresponsive, and we get something that compromise way too many things just to ‘please’ Apple.
And on top of that, there is no possibility of importing or exporting the equivalent of an “.aia” file, thus insuring to lock users in.
I will not play that game.
I mentioned several times in the forum there that, to be an adequate substitute, X would have to do EVERYTHING that Classic did, from the get go. THEN they could add bells and whistles if they please.
Instead of filling that gap, they insist on adding MORE bells and whistles while leaving the Classic users without even a properly working API 28 compiler.
The last straw was the denial of allowing new accounts/new users in Classic. There were people obviously developing in Kodular or AppyBuilder, and asking questions in the Classic forum (I assume because the community is perhaps not as extensive as it is in Thunkable and they could not get an answer in a timely manner) with the staff of Thunkable answering “switch to X”.
Sorry, but I thought this was a little condescending and nasty.
Kodular will be where I will be henceforth. Except from time to time, I will swing by Thunkable to notify orphaned users that they would be better treated here than there.
That goes without saying.
But then again, everyone is in this game to try and earn a living; and at some point, some are getting greedy.
I will not fault Thunkable for promoting their money making X environment, but trying to bully people into it by removing Classic will only have the effect of pushing people to Kodular.
I am going to have to agree with @CBVG that there are more then a few people such as myself that have taken the intended usage of a block based programming language to the extreme and Thunkable was able to accommodate us reasonably well even while they were developing Thunkable X they continued to support Classic to some extent and with out much notice they just flat cut us off from any future support, decide not to fix currently broken parts and then give us a date we need to either switch to X or move along. I have watched the development of X since the beginning and was very hopeful it was going to be a better solution but the longer I watched it the more I could tell it wasn’t going to work. I even discussed my feelings about what they were leaving out with them and got the impression they didn’t really care. The cost for X didn’t bother me and I’d have gladly paid it if they would have made it what they said they were going to.
So now I’m sitting with an app I was nearly ready to push out a new update for and hopefully have it working with Android 10 now only to find out the API 28 compiler was one of those things they never got around to fixing. I’ve been able to bring parts of my app into Kodular and knew I was going to have a couple of things to deal with before I even started bringing stuff in but tonight I tried to bring in the entire app tonight and not only does it not load but it crashed the IDE and the web browser tab I was using. It seems I have some extensions that are not compatible with Kodular on top of having an unknown number of components that are also not compatible. The parts of my app I am able to bring in also lags terribly. I mean it lagged on Thunkable due to the number of blocks but the lag while trying to do anything in the blocks editor here is REAL. I for one would gladly pay for the ability to work with large projects with little to no lag. When you get to the point just just trying to move screen with your mouse takes 4 seconds you start thinking real hard what something is worth to you. And this isn’t an issue with my Cpu…ram or internet. It’s just what happens once you get 4000,5000 or even 6000 blocks on a single screen.
Rebuilding my app is not really an option, I’ve spent about 2 years developing this on average of 20+ hours a week if not more, have 6 screens and I’d guess around 16K-20K blocks between all the screens. I have nearly 6K blocks on one screen and what is does is so technical that a single mistake will likely damage the object it’s working with. Because of this the blocks are not what I would call “Highly Optimized” but that was a trade off I made for reliability and to reduce the complexity of the code i was dealing with trying to follow jumps all over the place. Before anyone asks why I would possibly need that many blocks; my app is able to read and write the binary contends of a flash chip used in a certain type of Automotive engine computers. The app is also able to alter and build new versions of the binary image that have been read from the computer’s flash chip by switching out various parts of the file with alternative segments that others have created or remapped.
Maybe I’m wanting more then I should but in my situation but I’d gladly pay a reasonable fee for an error free aia import at this point or even some kind of utility that could tell me exactly what blocks and components were an issue with out having to sort though every single item in the app 1 by 1.
But other then that I really like what’s been done here. There are some amazing blocks that I’d love to put to use and I found more help here on my 1st post then I found the entire time I was with Thunkable so it seems there is a great community here as well.
The easiest answer is, use only components that are in App Inventor as you import a Thunkable aia into Kodular. So for instance ads, google maps, switch, toggler, fab, experimental, deprecated, artificial intelligence and sometimes even extensions should be removed. Builders have evolved so differently that you will have to be very lucky if you can import an aia without any problems. And even then it will not mean that everything will work. Standard blocks have also changed a lot between builders.
In fact I’m a PowerUser in the MIT App Inventor 2 forum since 2015, I know what you mean. There’s other PowerUsers like Hossein and Taifun who’s been there even longer.