I would like to have the possibility to change the device size in the designer to check component placement without needing to test the apk using an emulator. Adding some sort of storage for it should be also good. I mean to have the possibility to save the custom size giving a name to it that may be a phone model or anything else having a meaning for the developer.
1 Like
Hello Massimo
Pretty much impossible to achieve, given the difference in resolution, size and ratio between computer screens and Android devices. However, most developers are not defining their App for specific devices - you don't see that in the App stores because it is impractical.
There is of course a rough device sizing in the Designer (Phone, Tablet, Monitor). The way to build your interface for a range of smartphone sizes is to position and size components in percentages. Notes on basic GUI design on my website:
https://www.professorcad.co.uk/appinventortips#TipsGui
2 Likes
No, there are still problems working in percentage. It is viable for layout components but not for buttons, labels, textboxes and so on. The right way to manage them is using dp because it takes in account the different density of the displays so that the size of the controls is the same on every device. The Android Material Design Guide is quite clear about that so in my opinion App Inventor 2 should adhere to that standard. Anyway I am finding a lot of problems on color management in AI2, seems to me that setting the colours in the Designer and in the Block views is not consistent. I think AI2 is a very good "RAD" application so it is a real pity that it has these problems. I hope that my questions, observations, criticisms and proposals will be understood positively with the aim of improving AI2 and not as criticisms for its own.
1 Like
That is a flaw in the design though, same size controls on small and large devices? Not ideal.
So you didn't visit my website?
Raise that as a new Topic in the Help Forum Massimo, I'm sure we can help you get to grips with that.
All comments fairly put, like yours, are welcome.
1 Like
- I am not using only AI2, also AndroidStudio and VS2019 with Xamarin (I am also testing Embarcadero RAD Studio 11) so my observations about UI and measurement units came from years of development using all these environments.
- It is not a flaw to have buttons of the same size on different device, your finger does not scale as your device. Of course this is not true for every control, I normally use sp (scaled pixels) for fonts, dp for buttons, clickable and data entry controls, px for charts to use the best resolution possible, percentage for layouts (with some exceptions using dp).
- For spacers I use dp
- Yes, I visited your website and I mostly do not agree with your advices.
- At the moment I do not understand exactly when arises the color problems. I am not totally sure (I want to reproduce them using a little project) but seems some are related to dark mode setup in the smartphone and some to the Designer/Block views, until I will not understand better how to reproduce them I prefer to wait a little bit instead posting something that would be too confused.
1 Like
AppInventor is a typically educational platform. Designed to learn logical thinking and problem solving. We don't recommend building professional apps here. Sometimes specific solutions are used here that differ from the solutions that can be found in Android Studio. Sometimes it takes a long time to fix bugs or add features. Therefore, if you want to create a professional app tailored to your needs in detail, use Android Studio.
2 Likes
Honestly.... AI2 does not miss many things to develop professional apps, there are some AI2 clones or forks but they miss some important features:
- AI2 is open source
- AI2 may be installed locally and already exists AI2 Offline downloadable by sourceforge
- AI2 has a community and some engineers that are part of the community write good extensions both free and paid (at reasonable price).
I am using AI/AI2 since... well.. I did not remember but at least since 2016 to test embedded applications interfaced via Bluetooth/BLE/WiFi or "internet enabled" or also as a DB server because normally I/we did not design the app but only the embedded device (normally HW and SW) but in 90% of our cases we rarely receive the app before we end our design... so because for testing is not very important how the app looks I started to use AI/AI2 as a "RAD" for Android. After that, in 2019 I/we started to develop also Android app because I was tired of the continuous delays of app developers.
Now, having a very strict timing on the development of 4 new apps AI2 is the best option to complete at least the first release of them. What I can say is that the more "technological" part, the most complex part and the algorithmic part are working well and where done in very few hours, the result is very professional and good. The main problems I am experiencing are in the UI, the "look and feel" is good on the feel part, instead there are some problems on the look part but... in my opinion it is ver stupid do not fix these things because the quality of AI2 is not far from the "professional" competitors.
1 Like
tl;dr: This should be fairly straightforward to implement.
Historically, App Inventor was first engineered back when there was exactly one Android screen size and density. When Android started supporting more form factors/resolutions, App Inventor introduced the "Sizing" property of Screen1 where Fixed sizing attempted to scale the views to keep consistent with the original Android form factor and Responsive made the Screen size adapt the device's underlying size. When tablets became a thing, an option was added to allow for responsive sizing to switch between phone and tablet via a checkbox. A couple of years ago we decided this wasn't super practical either given the large number of device sizes. we tasked a student from Cornell to implement the dropdown that you see now. Internally though, the API was designed to take a width and a height rather than assuming the size of the device (there just happen to be hard-coded defaults). All we need is someone to implement a UI to allow adjusting the width/height values and then have those stored as part of the project settings so that they can be restored when the project is reloaded. It could make for a good student or open source contribution.
1 Like
Yes, that is more or less what I thought, a way to alter the screen size and to save in the drop-down with a meaningful name. For instance, I would add a LG-K8 (120x720) and a POCO M3 (2400x1080) with their model name and screen sizes. If this is a public setup in a short time I think we could have a relevant number of models available to everyone (may be we need to limit them).
Not now, I am short in time, but in the future I could help with some things, may be I would need some help at beginning and also surely I need to update my Java knowledge, I am note developing in Java since 2014... a lot of C, C++, Python and some minor things in JavaScript and R.
Most of the App Inventor developers are not going to need to deal with huge differences in devices like that (for those that do, there is a spreadsheet on my website covering many makes and models, added to on request).
In the case of those two devices, the GUI proportions would inevitably be different but even so, it depends on your market demand since a GUI designed for the LG would of course 'fit' on the Poco - if it can just be practical and not so pretty, that would be fine.
You can also have more than one GUI Layout in-App, using virtual screens, and display the GUI most appropriate to the screen size of the current device automatically,.
https://www.professorcad.co.uk/smartphonescreensizes#ScreenSizes
Probably you like to do a lot of unnecessary work. It is not a problem of market demand, there are too many different screen sizes with different resolution and density for Android smartphones, working with Apple models is simpler because there are 8 different models for a total of 12 different screens. And there are also the tablets... so the apps I develop for my customers are used by some thousand of people (professional market) or millions (commercial market) and I have to take in account the cost and time of maintenance, so your proposal is not acceptable. One app, sam code, multiple phone models, this is the road to follow. It is also still impossible to test an app on every different smartphone, also using an emulator, there are too many models so the right thing to do is to check the UI on littlest and the biggest screens finding the right compromise in its design. Actually the biggest smartphone screen is around 8"/8.2" and the highest resolution should be 2160 x 4320 (Sony Experia) so the solution is "dp to the rescue".
That is in keeping with my earlier notes! Since you requested the ability to target specific devices, I described a way of doing that now.
Well, there are better solutions requiring less work to support the same range of devices. The point is to do not design buttons and other touchables so little that the app is not usable and too big for bigger smarthphones. Using dp is a good way to be sure that a button has the same physical size in each case. Next, if you want to have the app looking similar in any case the strategy is to use percentage for the containers. If you want to maximize the resolution of the biggest smartphones you should think to reaize a UI that may stay on one screen for the biggest and scrollable for the others. Actually make sense to design to have the best results for 5" to 6.5" screens in xhdpi and xxhdpi.
...as indeed mentioned on my website. Let's see if MIT can enhance the Designer at least as described by Evan:
You could challenge the extension developers to provide this. An illustration of how the interface would look and a description of usage would help.
Extensions won't address the underlying problem as they execute on the device. To modify the user interface of the App Inventor editor, one needs to propose the change as a pull request on GitHub. It's possible that an extension developer out there may be willing to implement this and contribute it to the code base.
Indeed at least one of them has ventured into making an extension for the IDE - a Block "finder" that integrates:
I have tried it out on App Inventor. It's actually a FireFox extension. It integrates with App Inventor well, but it probably could be a bit better at the task.
1 Like