howdy, AndyD

how can I help you today?

howdy, yourself!

OK, here goes...

I'm working on a family of apps, each with the same functionality, but a different content focus. For example, imagine a family of tourism apps, each focusing on a different destination, but with the same functional capabilities. I'd like these apps to be able to live side-by-side on the same device, installed/uninstalled in arbitrary order. Each app would access its own database, but the preferences should be shared between and editable from any of the apps. What would be the best way to do that? I've been looking at the documentation for <manifest>'s android:sharedUserId attribute, and it seems like a good possibility, but I'm wondering what gotchas might turn up.

wow, you type fast

:-)

when you write "What would be the best way to do that", what exactly is "that"?

hah!

(BTW, howdy, Justin!)

Hey there

the best way to share the preferences between the apps

I wouldn't touch sharedUserId with a 10-meter pole

that's really designed for apps that are part of firmware

that's what the conventional wisdom seems to be...

I can see a few options

I don't want to have to have a "master" app that the other apps are "slave" to...

you don't really have a choice

well, I shouldn't say that

you either have tons of pain, or a different set of tons of pain

oh, good.

either there *is* a master app, or each app needs its own copy of the preferences

after all, if App A has the master copy, and App B depends on those, and the user uninstalls App A, App B is stuck

right.

so either that's expected behavior ("master" app) or App B needs its own up-to-date copy

probably what you will wind up doing is sending out a custom broadcast Intent when any app in the suite changes a preference

hmm, this feels like a peer-to-peer synch problem. I worked on something like that many years ago. Messy.

perhaps use a custom signature permission to limit it so other apps cannot receive those braodcasts

er, broadcasts

each app implements a receiver and updates their own copy of the preferences to match

and, yes, it's gonna be messy

hmm, OK let me mull this over while you help Justin...

OK

Justin: do you have a question?

I don't right now,but if I end up having one, I'll speak up :-)

OK

if either of you have a question/follow-up/whatever, chime in

while I'm thinking about your earlier feedback, let me ask something else... I know you've answered this question before on StackOverflow, but things change, so I'll ask again. Are you aware of any tools or techniques to automate publishing to the Play market? Going back to my earlier example, imagine 100 apps in the same family needing to be republished when there is a new version.

no

there isn't even an API for this

(not even an unauthorized one, AFAIK)

that's what I figured. Seems hard to believe that nobody's tackled this, but it would be a bear to keep it current.

not to mention violating Google's terms of service

really? didn't know that.

nothing regarding the Play Store can be scraped or otherwise automated, last I checked

hmm. Have to put my fast typing skills to work, I guess :-)

OK, I'm going to experiment a bit with your earlier advice and see how it goes. Thanks, Mark. Signing off.

So I have a question whenever you're ready Mark

go ahead

So I'm starting to use Fragments. I want to make sure I'm using them properly...

We should still have individual activities for specific UI tasks, but then use them to host fragments and arrange the fragments as necessary based on the screen size...

um, is that a question, or a statement? :-)

I should allow the workflow to be controlled by the activities, not the fragments, right?

that depends on what you mean by that

a fragment should only worry about its widgets and action bar items

In other words, I can add fragments to the fragment manager back stack and have a workflow of fragments all contained within one hosting activity

yes

you are also welcome to have activities host fragments as needed, rather than going with One Big Activity, as your last comment might suggest

But I don't want to do that in most cases, because then the fragments are also responsible for some of the navigation logic between different functional areas of the app (which would be represented in different activities)

um, define "navigation logic between different functional areas of the app"

Which is better? Multiple activities with just the fragments related to the activity or One Big Activity, or does it really depend on what you're trying to accomplish?

(BTW, howdy, Ron!)

OK...

(howdy to all)

Let's assume One Big Activity

I have a fragment that contains a login screen...

OK, let me stop you there

OK, good, I'm stopped :-)

why do you have a fragment for login, instead of an activity for login?

is there any scenario in which the login widgets will be on the screen as something else *at the same time*?

Well, I think you answered my question earlier, I'm putting too much responsibility in the fragment. It should just be responsible for worrying about the widgets and action bar items

And that's not what I've been doing in the fragments

So I think that's what the problem is :-O

well, at the end of the day, these are just Java classes, and so you can mash them up however

and, particularly in the Omnibus, I am going overboard on fragments in the core chapters, but that's mostly for "learning by repetition"

That's a good thing, because it's obvious I need to understand them better :-O

your initial statement of "individual activities for specific UI tasks, but then use them to host fragments and arrange the fragments as necessary based on the screen size" is spot on

OK, good. I think that's the direction I should be going in instead

but you only need fragments if there are screen-size scenarios where they will share screen space with something else

or in cases where fragments are a requirement (PreferenceFragment) or a quasi-requirement (PagerAdapter and ViewPager) of something else

There's a little of that, and also contingency planning for a tablet-optimized layout

I think you've answered my question though

let me take a question from Ron, and I can swing back to you in a bit

Ron: do you have a question?

I'm all good, thanks!

I have a simple app that has a login/pw screen. I now need to encrypt and store/retrieve on the device both of them. What is the SIMPLEST way to implement? Where should I look for any code examples?

"both of them" -- what is "them"?

The login and pw strings

OK

you have three major options

1. Use javax.crypto to encrypt the data, then store it wherever you like (file, SharedPreferencs, SQLite)

javax.crypto is from standard Java, plenty of examples on the Interwebs

2. Use SQLCipher for Android and store your stuff in an encrypted database

there's a section on this in _The Busy Coder's Guide to Advanced Android Development_

3. Use some third-party JAR to encrypt the data, then store it wherever you like (file, SharedPreferences, SQLite)

you'd need to get instructions on doing that from the authors of the JAR, and hope the JAR is Android-friendly

personally, I'd use #2 -- the biggest issue there is it adds 1-2MB to your APK size IIRC

Okay, I will proceed with investigation over the weekend... You can continue w/ Justin. I will have another question shortly.

Justin: do you have another question?

Not right now

My app allows for portrait changes and works great on phones but on tablets I get a strange behavior: When I change orientation, the screen rotates back and forth 3 times and then settles on the correct orientation!! Weird. One table is running 3.2.1 and the other tablet is running 4.0.x something.

I have never seen that effect

are these tablets from mainstream manufacturers?

Yeah, it only appears on the tablets. (We only have two at present so I can't say it is on all tablets). Yes, they are mainstream, XOOM.

I don't know what to tell you

if you can create a separate sample app that demonstrates the behavior, send me the source code for it, and I'll see if I can reproduce it

I'll research more and see if I can come up w/ something. Justin's turn as I'll prepare my final question.

Justin: do you have another question?

OK if anyone has a question, chime in

Old topic: Where to place the 'super.' calls in the onPause, onDestroy, Activity routines? I see that for onCreate, onRestart that the call goes first. But for routines leaving the Activity shouldn't they be executed just before exiting my override?

probably

I was a bit sloppy about that early on

and there does not seem to be any particular harm

I've been slowly adjusting my samples to do a better job here

Do we know for sure, i.e. is it documented anywhere in the Android community?

not that I am aware of

all Android requires is that you call it -- it'll crash if you forget

Okay, that works for me!

That is all I have for today, thanks again to all!

Justin: if you have a question, be sure to pipe up

OK, will do

running out of time -- any last question?

Nope, I think I'm good for this session, will talk with you on Thursday

OK -- see you (virtually) then!