Yet another multi-activity Android app.

[LaughingOtter]

Hi!
I'm in charge of building a somewhat complicated app for the Android. I know enough Java to do this, but I have been running into a couple of snags as far as the mobile bit goes.

The app opens on a standard login page, using the client's ID number/SSN and PIN number.
The app then makes an external call to our company's base server to verify the login. If the login is verified, an XML file is generated server-side and sent to the phone. The data in this small XML file (15-100KB) will be used by the app in different activities. The XML is read and persistently-stored. The app shifts to the main menu screen. The XML file also contains which tabs this main menu screen will make available to the user, which is why the file is generated and transmitted immediately after login success.

Now, all that works up to the point I actually have to make the switch to the next page! The error handling displays the correct messages based on the return string from the client-side script, but the whole thing dies as soon as I get to the Intent bit.

It may well be I do not thoroughly understand how Intent and Context is supposed to work. I have not seen a tutorial on the Web that details this (well, one that works, anyways).

I'm going to continue and hope I stumble across something so I can repost here and say, "OK, this works. Why does it work like that?"

Thanks for having me here!
Steve

[LaughingOtter]

So the correct way to do this is apparently to do the Login as an Activity, then switch to another Activity which generates the main menu, which then back-and-forths into different Activities which display each section of the client's readout.
This has not been an easy journey.

[peter_budo]

Wouldn't be easier to use fragments that can always query parental activity for "super" data and fragments do the rest of interaction?

[LaughingOtter]

sigh I guess I need to do even more research. Came across numerous Fragments references just getting this far. I think I'll go ahead and get at least two of the tabs up and running on this model, then double back for the Fragments research. My bosses want to see at least part of this app working or they'll try to outsource the project.

[LaughingOtter]

OK, maybe I better research Fragments sooner than later.

peter_budo: I understand your basic concept, and it actually would be more practical to use Fragments. Now let me see if I have this correct:
The Login portion of the app would be its own Activity, which, when authentication proves true, switches over to another Activity, which would generate the tabs available to that particular user. This Activity would actually serve as a hub of sorts. (I wonder if there is a way to actually store this menu as a reuseable object?)

Some tabs actually have two parts to them, a main readout and a detail readout (i.e.: for Claims, there is a summary page, each row of which would be a clickable object leading into another page which would provide more detail for that particular claim.) A Back button would return you to the Summary page.The Back button from there returns you to the Main Menu.

So, the Main Menu would be the actual Activity, and all the different tabs would lead to different Fragments? It would be mighty handy to have the parsed XML available to all the different Fragments instead of coding/using the same parser on each function page (horribly inefficient). "Super" data, as you said. Then I wouldn't have to use data storage methods either.

Incidentally, today I actually got from the Login screen to the Main Menu. Server-side authentication works. The SAX XML receiver and parser works, because the correct Main Menu tabs are brought up. So it was probably a good thing you caught me when you did.

OK, thanks for listening to me ramble on figuring things out.
Back to the books. And some more pinball once my brain starts to overheat.

Thanks, guys!