Were looking into Android for writing a tablet based system. Part of the design is for the system to be as modular as possible. One aspect of this is to display any "STATUS" activities in a side view on the screen. It looks like I can use PackageManager queryIntentActivities() to find the activities that show status information. But, can I display these in a single view all at the same time (via a linear layout)? The activities would be installed in separate apk's (features).
Can this be accomplished using ActivityGroup? Is this even allowed in Android? Everything I've read implies that Activities take the whole screen or float on top. This implies only one activity can be active at a time where as the design I'm thinking of uses the activities more like widgets.
You should be to be able to do what you want with just one activity, plus multiple (background) Services (on different threads) for your status updates.
Don't worry, you can still package them in different apks. You'll just need to sign them the same way, and your apks won't even be sandboxed from each other, so they'll be able to share the same data and share the same memory footprint of just one apk.
Also, take a look at NotificationManager, I know you want to roll your own solution, and you can certainly do that if you want, but you could also just reuse/extend NotificationManager and save yourself a bunch of work.
Related
i developed an app that contains a lot of activities and different application within the same app and they are all interconnected by sending different intents within it to function the whole app, however they still do different things and i can elimante one without hurting the other and causing the whole app to crash. so if i want i can divide them to be stand alone apps.
My question is this:
Can i have one app that download the basic activities and if a person want a specific activity they can download it (Eg: you download a game and that game includes a different set of levels that can be downloaded by pressing a button hence downloads that particular set of levels.)?
Forgive me if I misunderstood you, but are you talking about creating one big app that consists of many smaller apps, but rather than being all bundled in the beginning, a user can download each one as a module?
If it's this, it's not impossible, but not possible in the sense that I think you're hoping for.
Your one big app will still need all the necessary code and xml files because these need to exist when compiling. But what you can do, which is similar to what games do is to offer downloadable content that isn't code. Essentially, these are resources such as media files, text, or other data of the like.
Those data can be downloaded separately without affecting your app and it helps reduce the size of your app. However, the actual functionality of each individual app will still need to be within your app, but hidden until it's downloaded.
Typically, it's more common to just bundle it all together such as a Measurements app, or to have them as individual standalone apps such as Google Docs, Sheets, and Slides.
You're basically describing how a browser/website works.
If you really wanted to wrap this up as a mobile app, you could use webviews.
I am having some trouble working with Activities and Fragments. I am in the early stages of app development and am ultimately looking to design the most efficient way of integrating two separate screens.
The first screen would be the "Splash Screen", It would present the user with the Logo, the ability to enter user information and sign in through either a database or with Facebook. There would also be a button available to allow the user to register for the app.
The second screen would allow the user to set up an account by defining his user information and would include a register button and also a connect with Facebook button.
I would like to know how everyone would approach the task at hand as I had initially designed the app designating 2 Activities to handle each screen. Recently, I have switched to being able to host the screens as 2 fragments under 1 Activity.
What are the benefits of each approach and which design would you opt for?
Fragments are mainly for allowing you to display two separate UIs side-by-side on large-format devices. Fragments can combine code and UI within a single layout, and they also allow non-UI "activities", but mostly they give you flexibility in showing the various views attached to an activity.
I'd choose 2 activities, since what you're describing is a progression of operations rather than multiple views into the same operation.
I'm pretty much new to Android, but over the last two or three weeks I've managed to figure out most of its innards and how things work.
However, one thing is still bothering me - what's the basic difference between Activities and simple forms? Well, I know Android doesn't have such thing as a 'form', but by that I mean a fullscreen layout of elements that has an underlying class and all its functionality is executed in it, rather than in a process-wide class (Activity, to be precise).
As long as I understand, Activity is a separate process that's instantiated by OS to perform some actions that are basicly independent of the whole application. That also means that we can run only one of the application's activities, and it will still perform all of its functions without needing the whole application to be loaded. For example, if we have a movie player that can also convert movies from one codec to another, we can implement that functionality as a separate Activity so that other applications, like file managers, will also be able to convert movies between codecs using only that Activity, and not the whole application.
And that seems perfectly straightforward. The question is - why is everybody using separate Activities for functionality that cannot be separated from the application? In other words, people generally use Activities where I think simple forms within the same process would be more appropriate. For instance, I've seen people using a separate Activity for things like application settings, which obviously wouldn't be be launched outside the app itself, or editing application-specific data, which wouldn't be done outside the app as well, since the data to be edited should be selected from a list only known to the application.
Another example right from my experience - a unit converter application. It has a main menu with a GridView of units' categories, in each category there is a list of units and by clicking any unit we have a 'calculator' form for entering value that we want to convert. If I'd been doing that like everyone suggests I'd have three Activities - one for the main menu, one for the list of units and one for entering the value. But why? Why would I want to launch any of those three Activities separate from the application? If I'd want to launch main menu Activity - well, why not launch the whole application then? If I want just a list of units - again, just launch the whole application, it's not like some Facebook client is going to convert values between pressure units (since the list of units covers only one category at a time). And launching an activity for the calculator simply would not work, since it should return to the list to perform conversions and you'd have no list activity launched.
And anyway, even if I'm wrong and people use it wisely there's still an issue that Android SDK doesn't really provide any support for forms as I'm used to. Yes, there are things like ViewAnimator, ViewSwitcher etc. But all they do is switch layouts in their place, and that is hardly switching between forms as such. So the only choice to get close to that functionality at least is to use Activities. And we're back to the square one.
So to put it simply - am I missing something from the Android philosophy? Because I'm pretty sure that using a separate Activity (and a separate process as a result) for every single form in the application is an overkill. And if it really is and everybody knows that - why doesn't Android have any substantial form switching mechanism?
Thanks in advance for any clarification on this issue.
An activity isn't spawned in a separate process (unless you explicitly tell it to). Everything in your APK will be spawned in your process. Even if another application is using your Activity for whatever reason.
You can make your Activity "effectively" private to your application by not assigning any intent-filter to it in your manifest.
For the examples given, a form is equal to an activity. That isn't a universal statement as you delve deeper into Android, but for a beginner that's a decent analogy to make. Another common analogy is that Activities are more like web pages than traditional forms based UI.
I'm planning to develop and app that presents the users with several different screens (of different information).
Was wondering what would be the best way to implement this?
Is it better to have separate XML layouts and an activity to display and allow the user to interact with each screen of data?
OR would handling all of these in the same activity be more efficient (and dynamically load / unload each layout)?
I'd say you want to go with the former, in the most cases, but obviously it all comes down to what it is that should be changing.
If you end up having two activities with layouts that only slightly differ, and you have to pass a lot of data between them, then it probably should have been one activity.
But in the most cases, where you're dealing with presenting quite separate things, I'd definitely create one activity for each presentation, so that you don't have to manually handle things like the click of the back button.
An Android Activity is a single, focused thing that the user can do.
The easier way to explain it is: An Activity is a screen in your app.
You want to have two different screens, then you should have two different Activities.
I am creating an android application that has a lot of different screens where the user can navigate to those screens using the buttons or list provided in those screens. What would be the best way to design the entire app's navigation flow? Should I map each screen to be View or an Activity? Can an design an entire android app with just one activity and many views, where each view represents one screen with many other UI elements (buttons, lists, images etc)
I suggest you use for every "screen" that is significantly different from another screen (in both look and data that it is related to) a new activity. This gives you easier control and you don't have to mess up your code with plenty of variables to define different states. Using different activites you usually shouldn't have to worry about running in a undesirable or even undefined state.
To exchange data between activities you can use putExtra() to add "simple" data to an INTENT or for more complex data you can extend Application and use that instance as a singleton, which you then can access via (MyApplication)getApplication();
You really want to stay away from the single activity idea. That's actually an anti-pattern from the java model 1 web application days called "The magic servlet". I guess here it would be called "The magic activity". Each logical "screen" that the user interacts with should be an instance of the Activity class.
Modifying individual user interface elements based on user interaction is fine as long as it's just one or two elements, or just a portion of the screen, but for the most part you should be looking for reasons to split things out into their own activities, not looking for reasons to keep things together. In the long run it will make your code easier to maintain and understand.