If we look at one activity as a graph node, transition/calling from one activity to another as a graph edge, one android app can be conceptually converted into a graph. I am trying to see if there is any way to create such a graph starting from the first page/activity of an app.
Let us say we can use android UI test automator to help if needed.
I am trying to see if there is any way to create such a graph starting from the first page/activity of an app.
It would be exceptionally difficult.
I am assuming that you are trying to hack... er, I mean, "analyze"... somebody else's app. In that case:
You have no idea how many activities there are, unless you are reverse-engineering the APK. And even then, you have no idea how those activities will be used (e.g., legacy app that is putting activities in tabs and not using them as an ordinary activity).
You have no way to know what triggers the activities to appear. For example, a certain activity might only appear via an "Easter egg"-style bizarre set of inputs. Some might be triggered by things outside the app itself, like a Notification or a third-party invocation of ACTION_VIEW for some MIME type the app supports. And some of the triggers may be dependent upon other inputs (e.g., a disabled action bar item that becomes enabled only if you have set up an account elsewhere in the app).
With full source code, you could do static analysis to find all startActivity() and startActivityForResult() calls, and for simple variations you might be able to divine which activity starts which. Even that could get tricky in some cases, for complex Intent construction.
Related
In my UWP-App I want to create an app internal contactbook page. I can select a contact and return the selected contact back to the page where I opened the contactbook.
In Android where I come from there is a function called "startActivityForResult" which opens an activity gets the return value when finished.
I want to create the same behaviour.
I did this with Frame.Navigate(typeof(ContactBook)) and then when the contact is selected I navigate back with Frame.Navigate(typeof(PreviousPage), selectedContact)
The method Frame.GoBack() is useless in this case because I can't pass a parameter.
How can I solve this problem?
I'm not 100% familiar with android and "startActivityForResult" but are you looking to navigate the entire frame away? There isn't any equivalent in UWP apps, nor is there even really one for WPF's showDialog(), which is probably what you're looking for.
You only have a few options and none of them are really "amazing" per-say.
You can do what you've done above, which is navigate away to the page that has all the contacts, then navigate to a new page but depending on how your app is layed out you might be losing data on the page (since it's a new instance and not a back in the stack so you can't really cache it). You also can't navigate to an instance of a page either, it's only to a new page or through the stack from back / forward. If you use GoBack though and cache the page (using the "required" mode for caching) then you could do some dirty lookup of a stored value in a static class (I know, ugly and not MVVM) or setting a local settings value and reading that in the OnNavigatedTo() method for the page before.
If you don't NEED to use frame movement, you can use a flyout or a custom flyout user control to build a popup of sorts that will display the XAML for the page instead of a page frame. This will have a few difficulties with resizing (so more so for W10 than W10M) and such but you'll be able to not transition out of the frame itself. Then you can see the value of the selected and then on the submit event, you can just work with the page since it's already open.
If need be you could build a custom usercontrol for the flyout and put some custom dependency properties that can be bound for MVVM, it really all depends on what and how you're doing it.
So short answer, there is no fast way of achieveing what you're looking for and that does seem like an issue with the API. I would make the suggestion on the API's uservoice (https://wpdev.uservoice.com/forums/110705-universal-windows-platform) and try to get it upvoted!
There isn't any equivalent in UWP apps, nor is there even really one for WPF's showDialog(), which is probably what you're looking for.
#Daniel, no, there is a equivalent in UWP apps. Please refer to Launch an app for results, you can follow the tutorial in that doc to achieve this.
To do this, you will need to create two apps. One is the app which will launch the result app (let say "main app"), the other app here should be the contact-book app. The contact-book app will behavior like a modal window, and the main app will wait for the result of the contact-book app.
But in an UWP app, you can use ContactStore class to access the database that contains contacts.
So, you will need to reconsider if that is necessary to create a contact app by yourself.
Edit:
I may misunderstand your question, you just want your page to behavior like contact-book, not want to create a contact-book by yourself. But anyway, it's the same, you can create another app to hold your page which you want to launch from your main app.
I read somewhere that each time you call startActivity() to transition to a new screen, you are creating a new instance of that activity. This immediately raised a red flag to me.
In search of a way to prevent this issue, I read about using FLAG_ACTIVITY_REORDER_TO_FRONT. However I'm a little alarmed that this method is not used in any of the tutorials I've seen for opening a new screen in your app. So I think I might be missing something. I mean wouldn't you always want to make sure you're not creating a duplicate Activity? isn't this kind of a big deal and shouldn't tutorials address it?
I just want to make sure that I am understanding, and dealing with, this issue correctly, and using the commonly practiced way to transition between screens.
I understand in some cases you open a screen, do something, then close it using finish() and go back. But if an app has a complex 4 level hierarchy , and the user needs to be able to jump around between the screens?
I mean wouldn't you always want to make sure you're not creating a duplicate Activity
Most of the time you probably won't want to have two instances of the same Activity but I suppose there are situations where someone might
isn't this kind of a big deal and shouldn't tutorials address it
It is definitely something that Android developers need to know about and understand how to use. I would imagine that you may not see a lot of it in tutorials because most of them teach you the basics to get you started. When a developer is new to Android, they typically have enough to learn about the framework. And they normally show you how to do a few screens (which is often all someone may need). They expect you to learn more of the details by reading through the docs and using websites such as SO
I understand in some cases you open a screen, do something, then close it using finish() and go back. But if an app has a complex 4 level hierarchy , and the user needs to be able to jump around between the screens?
Yes, a lot of times you won't be getting too deep because the deeper the easier it is to get a "lost" feeling. This is why I like using Activities with a Dialog Theme when possible. It gives the feeling that you aren't actually leaving the screen you are on. However, that doesn't really answer your question. There are many flags that can be used with Intents to keep the stack from growing. The one you mentioned works and I also use Intent.FLAG_ACTIVITY_CLEAR_Top quite often if I need to clear all Activities from the stack and get back to one single Activity. There can be so many different situations between apps, users, and developers that how you transition and work the flow or navigation just depends on what you (really, the user) needs.
It seems like you are on the right track by asking these questions. Think about what will give the user the best and most natural experience and find the right flags in the Intent Docs for your situation
I hope this cleared things up for you a little. If you don't understand something, feel free to ask
You usually want to avoid creating a duplicate activity, and IMHO, it's a bug in the Android system that the default behavior is to allow it.
(Sometimes you do want to allow it, e.g. you've written a "get filename" activity, and more than one application is likely to call it.)
You control activity creation in two places: In the manifest, and in the flags of the intent that launches it.
In the manifest, the <activity> tag has the attribute android:launchMode, which can be one of:
"standard"
Default. Can be instantiated multiple times, can belong to any task, and can appear anywhere on the stack. Normally part of the task that called startActivity() unless the FLAG_ACTIVITY_NEW_TASK was used. A new instance of the class is created to respond to each new intent.
"singleTop" Identical to standard, except that if the target task already has an instance of this activity at the top of the stack, a new activity will not be created. Instead, the existing activity will receive a call to onNewIntent().
"singleTask" There can be only one. It's the first activity of a new stack, and is thus the root of an activity stack. If there are more intents, they'll be sent to onNewIntent().
"singleInstance" Identical to singleTask, except that it's the only activity in its stack. If it tries to launch a new activity, the new activity will start a new task. Same as if FLAG_ACTIVITY_NEW_TASK was in the intent.
I personally find the history back stack in android more confusing than helpful to end users. The use of back buttons can often not do what the user expects.
There are a few options available to you if you want to use activities as the main construct.
For workflow type activities (e.g. capture forms) start the first activity with Intent.FLAG_ACTIVITY_NEW_TASK and at the end use FLAG_ACTIVITY_CLEAR_TASK
For top level activities that are often a returning point start the activity with Intent.FLAG_ACTIVITY_CLEAR_TOP. This basically checks if the activity is already somewhere in the stack and if it is pops off every activity above it in the stack and resumes the original activity.
Another possible method for the top level activities is to use one top level activity and use fragments for moving around, e.g. tab browser etc. Then just use activities for actual separate tasks.
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.
Does anyone know of a way to show another class without creating a new instance?
It seems a bit crazy from a memory management point of view that each time you want to display a different form / page you need to use StartActivity which then creates a new instances of the class instead of reusing instances previously created.
Thanks in advance
I guess from what has been said - there is no real way to do it which won't hinder the "Back" functionality of the OS?
I'm building an app which is linear except on each screen it has a home button which then makes it possible to countermand this functionality and end in a loop - is there anyway you know of to destroy all over views and reset back to the main class? (IE prevent a memory leak from becoming a problem but also not damaging OS functionality)
Consider it a "clear history" without restarting the app
Not sure if this would work for Android (coming from a MS/C# background), but conceptually one option is to iterate through open forms looking for one with a specific handle. Then, once you find it, simply call the method to show that form. This would depend on there being a Java equivalent to the Application.OpenForms property in .NET.
It seems a bit crazy from a memory management point of view that each time you want to display a different form / page you need to use StartActivity which then creates a new instances of the class instead of reusing instances previously created.
Tactically, you are welcome to add FLAG_REORDER_TO_FRONT to bring an existing activity back to the foreground, so long as you understand the ramifications from a navigation standpoint.
However, your question is rather curious. How are you accessing StackOverflow?
Clearly it's not via a Web browser. Web browsers use the exact mechanism that you feel is "crazy", rendering Web pages even if that Web page had been viewed previously. They have been doing so for over 15 years, and we've been doing OK by it.
The Android navigation model is designed to approximately mirror that of the Web:
Users click on things to move forward
Users click on a BACK button to move to the previous thing they were looking at
Users click on a HOME button when they want to switch to some other major thing to go look at
By "reusing instances previously created", you're circumventing that navigational model. For example, let's suppose your activity stack were A-B-C-D, and you call startActivity() with an Intent for B and FLAG_REORDER_TO_FRONT. Now, the activity stack is A-C-D-B. When the user presses BACK times, they no longer are on the B they were looking at originally, but are back at A. In a browser, this would be rather strange behavior.
There are other flags on Intent, or attributes on <activity> in the manifest, that offer "reusing instances previously created". However, they are not there "from a memory management point of view". They are there where the traditional Web BACK-heavy navigation pattern does not fit your needs.
Assuming you aren't screwing up anywhere, Android will destroy under-utilized activities, garbage collect that memory, and even return that memory to the OS.
I seem to be missing something obvious here, why would I want more than one activity per application in Android? Does somebody have some solid examples?
Suppose you are creating a game. You need to have at least two activities - a welcome screen, and the actual game screen. The third activity in this example might be a settings page of the game.
Another example.
Suppose you are developing an application and you need to pop up a dialog, i.e. asking user to set username and password (Standard login screen). You might choose to create and activity and apply a dialog theme to it.
Think about it as the form of desktop application. you don't put everything on one form do you? :)
Sorantis' answer is spot on. Here are other thoughts as well:
Most Web applications, even AJAX-y ones, don't try to have everything in one single page. Some do, and those tend to be the ones that are slow as molasses to load (Evernote, I'm looking at you), have code that looks like a heaping mound of spaghetti, etc. Android is no different.
Also, state management for a super-complex Activity will be nasty, causing you problems with screen rotations and supporting being kicked out of RAM because you screw up onSaveInstanceState(). Memory management in Android assumes lots of cheap activities, not fewer massive ones. Intelligently handling the BACK button requires gobs of your own logic. If you want multiple entry points (e.g., Launcher icon and a MIME type handler and something some other app can call with startActivityForResult() and a search results handler), doing that in one activity will be a nightmare. And so on.
One very basic thing that makes having multiple activities in your program desirable is the use of the back button. I have a form in app after the user clicks search he is presented with another activity showing the results of the search. If he wants to change the search parameters he just can press back and without me doing anything particular he gets back to the search form. Doing this with one activity would be a lot of work for you.
The next thing is the memory management. Android will trigger the garbage collection automaticaly after changing activities that means my whole search form leaves the memory and doesn't take any resources away from the user.