Is it possible to have one app icon with a home screen that provides access to multiple apps (without icons) developed and deployed independently, or does that contradict the android app paradigm altogether?
My product managers basically want me to copy a web app that has multiple sub-features which we deploy separately, each with its own api, and do it in android. What i think i'm learning is Android can be organized with modules in the solution but is not built to be deployed separately, and breaking the web app down into multiple independent android apps that don't have icons but are called by another app is not usual for some reason.
The only thing that puts an icon on the home screen is the LAUNCHER category intent in the Manifest. You can always start other apps on the phone given you know their package names.
That being said, if the apps are developed and deployed independently, then it does seem against some paradigm to require the end users to install multiple apps just to get the full functionality of what you are independently developing.
Related
I am planning to develop a Flutter App which will be installed on a dedicated device which I want to sell to customers (B2C). This device will be used only with the developed app and thus represents a kind of customized end user device, which hasn't to provide any other functions. For example, the user should see a customized boot screen and then my app should open. The user should not be able to access the Android system apps (Config, System Bars, Home Screen, Home Button/Navigation).
In doing so, I have the following problems:
What options do I have to update the app automatically?
I have read that there should be something like the Managed Google Play Store, but would this even be the right use case for this or should I rather write my own service which is responsible for updating my app?
How can I make sure that the user only uses my app and not other apps or the system menu? The following link (https://developer.android.com/work/dpc/dedicated-devices) describes how I put certain apps into "Lock Task Mode", but that is mentioned more in the context of Enterprise Mobility Management, not for customized consumer devices. Is this even the right way to go for my requirement, or should I rather look into the AOSP project (https://source.android.com/)? That would certainly add an additional hurdle. My preference would be to be able to use any Android tablet for my App.
In order to sell my dedicated device, I will need to customize/install a variety of devices, which begs the question of how do I effectively solve this? Do I need to flash the devices to do this? Is there possibly another effective method such as customized installation scripts via adb? This question is certainly closely related to the previous question.
I want to create folders or application groups on the Home Screen of an Android tablet for already installed apps.
The apps APK will be provided by someone external (I can't modify them). I need to create a script, a small app, or something similar that when executed look for the specific installed apps in the connected android device and then creates apps groups on the home screen.
For example, if I have 8 applications installed on the android device then I need to create 4 groups of 2 apps in each folder.
I'm totally new to Android developments although I have some experience with Java, any insight of where to start looking will be welcome.
The device Android version is 10.
I also was looking for an existing solution like this APK Installer, but it doesn't have the option to create the folder/groups.
I need to create a script, a small app, or something similar that when executed look for the specific installed apps in the connected android device and then creates apps groups on the home screen.
Android, the operating system, has no concept of "app groups". That is a feature of a launcher app. Some launcher apps may have APIs to allow third party apps to manipulate app groups, but the details would vary by launcher. On the whole, I expect very few launchers to have such an API. And, if you were expecting to be able to do this for arbitrary devies using arbitrary launcher apps... sorry, but that is not possible.
Short:
Is it possible to write a mobile application where you can download some kind of extensions/add-ons (like in desktop programs) that are not previously shipped in the app archive?
Long:
I am developing a mobile app with a shared base functionality but different modules for different clients. As the app is growing rapidly and the modules are quite different, it would make sense, not to pack every module into the apk from the beginning but to ship only the base code to all clients and they can select and download the modules they would like to use. Regarding apk size and speed this would offer definately advantages. Splitting the app into several smaller apps with different package names on the other hand would be very hard to maintain. Currently I'm using Ionic but the question would be equally interesting for native apps.
Searching the web returned nothing of value, so I'm wondering whether there is a way to acchieve this...
Well, i'm not sure if you can have a class loader as you have in Java for doing such things. But the res folder probably will not work.
Another approach is to launch every plugin as a different application, and design those activities to work with startForResult so you can communicate and open all other apps while looking like you are within the same application.
in my company we plan to develop an app with different modules. We develop Apps for Apple, Android and Windows. We have some default modules like inventory and relocation, but for some customers, we need to develop custom modules. The question is, what is the best way to provide this app to our customers and how we can use update functions?
If we build one app with every module, and just unlock the modules based on the customers licence, it will be massive inflated, at the time. We have up to 20 customers and each of it needs 2 or 3 custom modules.
To build 20+ apps and distribute it over the store, it will be really difficult to manage each app. And if we update some core functions, every single app must be updated. Not a good way.
So what is the best way to develop custom apps for our customers and ditribute and update it?
sorry for my english, it's not the best..
So you don't want to include all modules in every app installation, and you don't want to distribute many different versions of the app, each one with a different combination of modules.
It seems to me that the only solution you have is to download your modules after the user has installed the app and chosen their license.
The easiest way to implement this is with a web app as opposed to a native app. However if you want to write a native app you are able to download and execute binaries at runtime.
This thread contains a few different approaches to achieve that:
Is it possible to dynamically load a library at runtime from an Android application?
Good luck!
I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?
In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).
Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.
Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.