Things are changes when time passes, so, to me, it is better to follow latest guidelines of Android for App Inventor. Because App Inventor apps are even working on first releases of Android which is only 5% of people (API < 19 ) using. (source)
So I think dropping support for old versions and focusing for latest versions is better for App Inventor, so App Inventor can add new features to the platform like full implemented Material Design, because newly created apps on other platforms are already supports Material Design. Or Background services, or better Adaptive Icons support. I know other App Inventor forks/clones working for latest features but seeing that for App Inventor itself would be better. Maybe these things will require a major redesign/remade for App Inventor, but I think it will grant a lot of benefits for MIT Team about adding new features easily and users who are using App Inventor for creating apps.
Sorry if I said anything wrong, I just wonder how App Inventor will continue its development in the future and wanted to talk about it.
Depends where you live and the resources available. If all you have is one older version Android phone shared among forty/sixty students, App Inventor is your friend.
If you want to use all those things you have listed that App Inventor does not have, you could move on to another platform. Background Services will need a different type of programming using a language such as Java or Kotlin.
As an Educational Platform, App Inventor doesn’t necessarily need to be concerned with a lot of the Android environment - better to focus on what works for STEM and making the IDE easier to use.
I understand what you mean, but I also think about if App Inventor would use latest technologies, it will be more easier for MIT Team about adding new features and more helpful for users. Because also I know most of people wants to contribute to App Inventor sources (and me) but they can't because of sources looks so complicated to understand how an APK is created, how App Inventor reads an AIA, how blocks added etc for a person who is not master in any specific programming language. So only we can "use" the platform, and this is not helps MIT team in any way. I can see all repository is about 400-500 MB when cloning the sources to local and it is increasing in almost every commit. So makes impossible to understand "how actually it works" for anyone when looking at a lot of files, scripts etc. An educational platform is about backend and frontend, not only frontend for me.
Hi Chris, thanks for your feedback here. Can you please stop emphasizing AI is for educational purposes? What we have noticed is, whether or not this is true, it puts students and developers in a bad mood and not want to use the product or even get started. Hope you can understand. Thank you.
There are offspring versions for commercial use if you don't want to use App Inventor, which is, first and foremost, for education.
Check out Thunkable or Kodular, which are Blocks driven like App Inventor, born out of the same Google cradle and largely based on App Inventor Open Source.
You might also consider a text-based language such as Java, Kotlin (both Android Studio) or B4X (similar to Basic). There are many others too.
it puts students and developers in a bad mood and not want to use the product or even get started
All who are genuinely interested in software development never stop learning.
@ChrisWard thank you for this feedback. Very much appreciated.
Main point was just trying to make with that is that the “for educational purposes only” makes AI2 sound cheap and flimsy when that isn’t that case. But I’ll just remind everyone - Students don’t want to learn extra stuff and teachers shouldn’t waste their time with bells and whistles. If you want to pack a classroom where every student is foaming at the mouth to absorb every piece of information at the edge of their seat then show them how to spin up a quick app, get it to market so they have a chance at turning the 50 grand they need to pay off their student loans.
This is actually a subject of intense ongoing debate here on the dev team. One of AI’s goals is accessibility. Support for old platforms is very important to its mission.
As time goes on, however, it becomes more and more difficult to support the oldest operating systems in our current system specifications. At what point do we have to drop the oldest ones? We still really don’t know.
@Susan_Lane this actually clicked with me this morning, totally agree agree with it being fundamental part of the mission, new app inventors take this for granted. And I think experienced app inventors can sonetimes too. You know I’m not sure of the actual scope of what the MIT team is facing with this but I’m sure it’s tedious and tricky, but something interesting to just look at could be the concept of i18n. I’m not talking about using it for languages, I’m talking about the concept of it and maybe seeing if it can be applied to Android/ iOS versions …
I know what you mean but writing extra code for specific Android versions makes App Inventor bloated as it increases the code length. Most people always drop support for old versions which is not used by people anymore. And doing the same for App Inventor can allow MIT to decreasing the difficulties.
For example, supporting 2% of people effects other 98% people in bad way for App Inventor. We can take CardView (or Cards) as example, in older Android versions there was no CardView, so because of App Inventor supports older Android versions, other people who has latest version of Android can't use it that too.
To fix the confusion, I just worried about the future of App Inventor that's why I'm saying these. Otherwise App Inventor is already good platform.
Rather than exclude anyone (the 2%) perhaps a version system could be used. Identify the target device/API level, and the correct version of the AI2 app is loaded for use. This might exclude bleeding edge features for later devices - API > ?, but at least the developer will know it will work on their target - for everyone.
One of our Google Summer of Code students implemented CardView last summer, actually. Merging it was slowed down because several other changes were developed in parallel, and that was the logical one to go in last. I’m working on finalizing the pull request now.
Regarding versions, you’d be surprised how much usage there is for fairly old versions of Android.
You can make a pretty good case that the very oldest versions we support are in such sparse use that it isn’t worth the amount of work it takes us to support them. There are still a few years worth of Android versions in active use.
If you really want a tool that is tuned for the most cutting-edge part of the world, you’re probably better off with Kodular or another commercial project using this codebase.
Worth noting: We aren’t holding ourselves back to Android features only available in API7. We are making as many features available that far back as we can and ensuring that applications developed in our Designer won’t crash on versions that old.
We're an educational tool, but we're open source. There are some forks of MIT App Inventor that support professional developers. Take a look at Kodular and Thunkable.
