I code Adobe AIR games with Flash Builder IDE. When exporting release version, the Android one offers two options: one with embedded active runtime and other with shared AIR.
Which is the best option should we choose? In case we select shared AIR, is any risk for our games? I mean, is this true that all Android device always have AIR now? (For us a smaller APK is always better, right? :D)
Normally which option do you choose?
It is not true that all Android devices have AIR installed. Likely it's far from it (though unfortunately I have no empirical data to give you - other than Adobe's blog which in Spring of 2014 claimed 50 million+ installs)
So while you will hit a very sizable % of potential users (using shared AIR runtime), there is no guarantee that the end user will have the correct (or any) version of AIR installed on their Android device.
So if you want to target the broadest audience possible (at the expense of filesize), you would want to export with the run time embedded.
Of course, some users will be put off by your app if it's too big (especially the gamer crowd) so you have to balance that with having to inconvenience some users with downloading AIR first.
Only you can decide what is best and you should consider the following:
Who is my target audience? (gamers are more likely to have AIR already installed), casual users are way less likely to bother with AIR or know anything about it or updating it
How big is my app without the runtime? If you're app is 200mb by itself, then adding the runtime doesn't really make much difference. But if your app is only 2mb, then you're getting a 4-5x bloat.
You do want embedded since this is a guaranty that your game will work correctly. If you choose shared then your app won't install on system with an older AIR runtime version and user might no know how to update it so they won't be able to try your app. Embed and you avoid all these potential problems.
Related
I am new to Flutter and dart language. After developing some example apps seeing from the tutorial I have come to know that the simple Tab-Layout App is taking 7MB for APK after release and after installing the APP the size is 27MB. My question is as follows:
What is the difference between the APK Size and Installed APP Size?
When developing an App whether its Native or Flutter, what should we keep in mind that APK size should not be huge or the size of the APP after installing should not be huge?
Keeping in mind of the all pros and cons of Native and Flutter, what is the best approach to develop an Android APP?
Installed App has something like the DOUBLE in space of the standard APK, this is cause by how Android "installs" all Apps. If you open a folder in "/data/app/..." you can see that for each PackageName/App it is stored the standard APK file (the one you release) and there are at least two folders: for libraries and one for optimized code (not accessible/readable from us without Root). These folders contain other extracted and optimized files starting from your APK.
Flutter Apps cannot be smaller than 6-7Mb because it brings all Flutter Core inside them. To "shrink" your App you can follow common rules to shrink any normal Native App.
The best approach? All depends on your skill, how much available time you have to complete the App, how much times the Customer change his minds about the position of some graphic interface, etc... Flutter main website page has written "Flutter is Google’s mobile app SDK for crafting high-quality native interfaces" so the main purpose of it is to quickly create Interfaces. This is good when a Customer interrupts our work every 10 minutes because he wants to change something in the graphic aspect and we cannot manually change many XML and then rebuild a version each time, so Flutter could improve this step a lot. Flutter is even good at initial stage when we are not sure where we will set components/widgets at final stage, so we can move all the stuff in few seconds to check the graphical result. Performance of Flutter Apps are quite good, but not good as a Native App obrliviously. Using Flutter could be the good way when you already know that the final APK will be bigger than 25MB, because in this case 25MB or 25+7MB is not that's difference but the speed (in GUI development) provided from Flutter are something not estimable.
I have a feeling I already know the answer to this, but I'm still hoping it's possible. Awhile back, I made an app for android using an Adobe Flash trial. Since then, I've made numerous similar apps in Android Studio, which look much nicer and don't require the user to download AIR. For whatever reason, the app I made in Flash is doing really well, despite the fact that it's easily the worst one I've made. What I'd like to do is replace the app with a remade, nicer looking, native version of it. Is this possible somehow?
Yes. The only requirements Google has for Google Play is that your application have the same package name (e.g. "com.example.myapp") and is signed with the same certificate. It also requires a new, higher version code and will prompt a user for a manual update if it requires additional permissions.
Google does not compare the contents of the APKs for similarity, so do what you want as long as you have your certificate.
But - is your "app" an app or a webpage? The Adobe AIR APK is a native app. They just provide a framework and toolset for constructing apps.
http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html
More specifically, Adobe uses the same distribution method for AIR apps as native apps, so re-distributing as a native app is possible:
http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac-77bd3ea112e2c0a7ed0-8000.html
I work at a large company that is looking at building apps for internal use only (iPhone/iPad). We are looking for a SIMPLE way of creating apps that essentially are just a web browser with a predefined URL and no address bar/tabs, etc. Essentially a very dumbed down browser with a custom logo. What is the easiest way to accomplish this?
We would obviously be distributing these oursevlves and they wouldn't be available in the App Store, so app guidelines aren't an issue. We are on Windows boxes and are Java/Web developers so we'd rather not get into too much C sharp if at all possible, fyi. Basically it'd be nice if the tool (if one exists), were to allow us to give it a URL, an icon image, and it builds the app from there.
And while we are starting out with Apple devices, we need to be cross platform compliant with whatever tools we use because I can imagine the day when they decide to buy Android or WindowsPhone devices later on.
MobiOne? PhoneGap? Appcelerator Titanium SDK? Can either of these do what we need? Something else?
A big 'No' for MobiOne. I bought it for 99 dollars. As they advertised, I was able to create a static app within hours. But that's pretty much what MobiOne can do. The moment you start using html, javascript or even audio, all sorts of problem seem to creep up. And there is no support in their forums either. My basic question about using the audio player remains unanswered for a month now.
Here is the worst part:
The tool has a poorly built emulator. Often times, my app worked fine in the emulator but failed to run when deployed to a real device. And at times, i have seen the vice versa too.
Since then, I switched over to PhoneGap(which is free). It took me 2 days to just set my environment right. But once I had the environment setup, it took only minutes to deploy my app in to a virtual device.
Looking at your requirement, I would say that your safe bet is PhoneGap.
I don't have a working knowledge in Titanium but I read in a lot of forums that it supports less platforms when compared to PhoneGap. Titanium seems to give a more native feel to the app but that also means you cannot port it to multiple platforms without changing the code.
Apple may reject your app if all it does is wrap a web site in a WebView. You need to have more functionality in your app than just loading a web page.
From the app review guidelines for iOS:
2.12 Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected
You would need to add additional screens to the app like an about page and a contact us page in order for your app not to be rejected.
As you say you know JavaScript, look into appcelerator.com it allows you to build cross platform apps and only writing your code once.
I would re-evaluate your reason for wanting to create these projects as an app in the first place. What app functionality do you want that you don't have now with your web page? You didn't mention anything in your question that would indicate this needs to be an app.
On Apple devices, you could create an icon that points to a web site. You could define the pages in a way that hides the address bar. Lastly, the web pages could easily be cross-platform already.
Wrapping this into an app would just possibly complicate the process. You may need to deploy updated app code to the device, where a refresh in a browser works just as well.
I have been researching PhoneGap and I'm now at an impasse and need some advice. I know that PhoneGap essentially 'converts' html5,css,JS sites to 'apps' for distribution, which leads me to my question:
Why wouldn't one simply utilize a webview within an activity to do the same thing and keep the app native?
The advantage of PhoneGap is that it provides APIs that enable your HTML/javascript to interact with the phone (e.g. camera, accelerometer, media etc.)
These APIs are standard across multiple devices (iOS, Android, WinPhone, Blackberry etc.). So you can write one set of HTML/javascript and deploy to multiple platforms.
If you just created a WebView you would not have the PhoneGap APIs and you would need to build containers on each platform you were interested in.
Good question I have searched me too, because we went in Phonegap solution and I think it is a wrong way for us.
The long story:
That is very true if you write once a UI with web developer skills than not needed to know native language and it compile, and ready for testing.
Web developers are more so higher the demand => developer price even cheaper.
When the client want a Milestone 1 for his great idea it will ask a few company, freelancers about development price and time. If is a very basic application version with Phonegap you will have the less development cost( off if your web dev skills are the same laver as platform dev skills) with webView at second place and last one the native.
The client is satisfied with app result buit with Phonegap and want to get more investors so it will make a presentation, where they are asking more features.
At Milestone 2 you will add a few features. Some are easy command line install and you get it, some aren't. Maybe you will be unlucky as you want a combination of 2 existing plugin with a few extras. The conclusion will be: you have to develop a plugin. At this point is already a very big sign of interrogation which is cheaper: the Phonegap + Phonegap plugin or a WebView. If you need 5 existing plugin and your has a little modification, than still Phonegap. But if you need only 1 plugin, only yours, than the web view is the proper way. There are also cases which makes the Phonegap stucture useless. Also there is a problem with version control system under Phonegap if you develop web files, and native code too: some are regenerating at each build time some not. Still is expensiver the native platform. Now the required features are developed. The client will make a demo for investors, where will be visible execution speed with this new features. Or here they will require optimisation, runtime speed-up or after publish to market they will see some are running with low end phones and not the ultimate, which ws used at demos and they will decide to go to Milestone 3 : speed up.
At optimisation, speed up (Milestone 3) you will decide as you need native GUI. After all GUI developed with web now you will need to throw out at fence and implement the side, maybe some parts need even NDK to speed up. No way to be good here with Phonegap. But you have hired web developers, or contracted that company. Now go back to that company , developers which can make native code. They will not start from 0, so they need to analyse the code, refactor and your development price will go up at least with 50% as you would start it from 0 with native.
Good Question, you still could use webview for that but you won't be able to access native functions like ringtone, camera, and all that, however, the app done that way will be regarded as a native app.
(Sorry for my english)
I'm new using Android (in fact, I'm just testing android) and I have a lot of questions...
Well, let me explain you the situation. In this moment, in my job, I am writing my code with C# and run it on Windows Mobile 6, the apps are used to make sales, send bills, reserves, etc. The devices (iPAQ 216) are given to the salesmen, and they must use the apps and update them via internet.
Each salesman have a unique client list, unique data and (in some cases) an unique set of apps, which means that I need to prepare a different package for each salesman. Using a Microsoft tool (cabwiz) I can prepare automaticaly a different package for each one of the 150 salesmen. They download their specific package using a tool wirtten by me, and install it and everyone is very happy (maybe)...
Is that possible in Android? How? and if it is not possible, do you know an idea how to accomplish somewhat like that...?
It's not going to be as easy as cabwiz, I can tell you that. But it would be possible, theoretically, to write a script that modifies/generates the unique portions of the source and then compiles a new copy for each user.
If the only difference between the apps is the data on them, then there is no need to generate a different package for each user: have the app download the data from your server and save it after the app is installed. You could also make some modules (I can only guess what kind of functionality you're talking about with regards to different apps per user) only accessible to particular users.
Yes, it's possible however:
You may want to look into writing in java rather than C# as that's more officially supported on android
There are some limitations of the android APIs, in particular there are basic behaviors of the device that can't be altered - without rooting there's no equivalent to the "hook" functionality of windows.
Make sure you get devices with the menu option to enable installation of applications from 'unknown sources'; otherwise deployment will be a lot more difficult. At that moment, this amounts to avoiding AT&T, as their devices presently confine you to the android market or physical connection to a machine running the developer tools as distribution channels. (As a work around you can upload your apps to the market and not publish them, though that won't fully keep them private unless you also include something to require authorization when they run. You could also install the minimal set of dev tools on the salesmens' laptops)
You will probably want to learn about the command-line application build tools and scripting in order to generate a custom apk for each salesman. Once the devices are set to allow unknown sources, you should be able to email the salesman the apk (or a link to it) as an attachment. You should also be able to make the custom apk refuse to run except on a device matching some fingerprint data you've previously collected. While you can develop for android under windows, you may want to look into switching to linux in order to make some of this scripting a little more natively elegant.