Office Hours — Today, April 4

← Thursday, March 29

Mark M.
has entered the room
Mark M.
turned on guest access
David
has entered the room
Mark M.
howdy, David!
David
Hi Mark,
Mark M.
how can I help you today?
David
View paste 
I have to keep data, even though the app is crashed.
In order to protect data, a file has created in internal memory under data/data/<packagename>/file/file_name. 
When the app is crashed, will this file be safe?
Mark M.
assuming you successfully wrote to the file, yes
see: http://android-developers.blogspot.com/201…
David
Ok. Will sdcard be safer?
Mark M.
not especially
Gene
has entered the room
Gene
Hi
Mark M.
in fact, it would arguably be less safe, since it may not be availabl
David
Thanks
Mark M.
er, available
howdy, Gene!
Gene: do you have a question?
Gene
Hi Mark, I have a question for you.
David
Will rooting steal data?
Mark M.
(David: let's let Gene have a chance -- I'll get back to you in a moment)
Gene
I'm trying to use a shared preference between two separate apps
Ron T.
has entered the room
Gene
both with the same shareduserid
In Gingerbread and above, this work: pref = appContext.getSharedPreferences(pid, Context.MODE_PRIVATE);
pref results in the shared preference of the appContext I pass in
Ron T.
Hello to all!
Apr 4
7:30 PM
Mark M.
there is no getSharedPreferences() that takes a pid
Gene
but in Froyo and Below, I get a sharedpreferences object back, but when I try to access any of the shared prefs, its null
Mark M.
(howdy, Ron!)
Gene
Oh, sorry, pid is a String I pass in with the name of the SharedPreference
Mark M.
where are you getting appContext from?
Gene
pref = appContext.getSharedPreferences("name_of_shared_pref"m Context.MODE_PRIVATE);
Mark M.
no, that is where you are using appContext -- where are you getting it from?
Gene
otherAppsContext = createPackageContext("com.fishstix.myapp", 0);
Scott
has entered the room
Gene
appsContext = createPackageContext("com.fishstix.myapp", 0);
Scott
hi all
Mark M.
well, I would have expected that to work, but I have never used createPackageContext(), and I really really really don't like sharedUserId
Gene
In Gingerbread+ it seems to work just fine. But in Froyo or less, I get the SharedPreference object back, but all its contents are null
Mark M.
(howdy, Scott -- you are in queue behind Ron)
presumably they changed the behavior with Gingerbread
Gene
Is there another method of sharing a SharedPreferences object between two apps?
Mark M.
View paste 
I tend to look at it as "sharing data between two apps"
there are plenty of structured ways of sharing data between two apps (ContentProvider, remote Service, etc.)
Gene
I suppose I could use a contentprovider, I just thought I had figured out a quicker/easier way of doing it. =(
7:35 PM
Mark M.
sharedUserId is a scary thing
for example, you cannot change it, ever, without locking all existing users out of their data
Gene
with a content provider, can I limit access to just my two applications?
Mark M.
yes, you can check the calling context to see what the package is (see static methods on Binder, IIRC)
if you can avoid the sharedUserId, I would recommend it
Gene
Alright, thanks for the great advice Mark.
Mark M.
Ron: your turn -- do you have a question?
Ron T.
View paste 
I am using a MultiAutoCompleteTextView and it seems to work okay except for the following: With the focus in the MultiAutoCompleteTextView, hitting the 'NEXT' key on the soft keyboard does NOT move the focus to the next field (which is a simple EditText). This behavior is the same on different devices and in both portrait/landscape. Am I missing something? (I don't really want to start intercepting keystrokes if at all possible).
Mark M.
does NEXT do anything? or just no response?
Ron T.
No Response
Mark M.
I haven't used MultiAutoCompleteTextView, but it feels like a bug to me
next should be next for all flavors of EditText-ish things
Ron T.
I've posted on StackOverflow but no replies.
Mark M.
got a link?
Ron T.
No
I'll try to get one
Mark M.
find your question and post the link here -- I'd be interested in taking a look at your layout, and I assume (hope?) you have it in the question
let me take the others, and then I can swing back to you
Ron T.
http://stackoverflow.com/questions/1001414…
Mark M.
Scott: your turn -- do you have a question?
(Ron: could you update your SO question with a copy of your layout?)
7:40 PM
Mark M.
Scott: your turn -- do you have a question?
Scott
just listening
Mark M.
ah, OK
Ron T.
Will do!
Mark M.
David: back to you -- do you have another question?
David
Ok. Can rooting device steal data from the device?
Mark M.
There's a saying: guns don't kill people -- people kill people
similarly, rooting doesn't steal data -- people steal data
people who root their devices have access to any and all information on those devices
David
So, Should I encrypt data before storing into file?
Mark M.
why bother? they'll decrypt it
if you have data you do not want the user to have access to, do not store it on their device
David
I see.
Mark M.
now, encrypting data *on behalf of the user* may be a fine thing, to prevent third parties from getting the data
but you cannot defend yourself against a sufficiently motivated user
Gene: do you have another question?
David
Thanks
Gene
No, I'm just listening now. =)
Mark M.
ah, OK
Ron: do you have another question? Or do you have a layout I can examine related to your first question?
Ron T.
Layout is out there now
7:45 PM
Mark M.
really?
they must have some caching going on -- it's not showing up here
I thought edits were in real time on SO...
Ron T.
Layout won't save, says formatting error?
Can I paste it here?
Mark M.
if it's not crazy long, sure
Ron T.
View paste (66 more lines) 
<?xml version="1.0" encoding="utf-8"?>
    
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="@drawable/backgroundonly"
    android:weightSum="1"
    >

   	<TextView android:layout_weight="@dimen/FULL_LAYOUT_TOP_Weight" android:id="@+id/tvCreateMessageSeperator1" android:layout_width="wrap_content" android:layout_height="0dip"/>
    
    <ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
    			android:id="@+id/svMain"
			    android:layout_width="fill_parent"
...
Mark M.
with respect to SO, when pasting code (or similar stuff), highlight it and click the {} icon in the toolbar to get it to format it as code
Ron T.
Thanks, I'm a newbie still!
Mark M.
have you tried specifying android:imeOptions="actionNext", rather than just going with the default?
Ron T.
No, I'll try that now if you want to go to someone else
Mark M.
yeah, give that a try -- it might help
David: do you have another question?
7:50 PM
David
No
Ron T.
android:imeOptions="actionNext", WORKS GREAT!
Mark M.
good to hear
perhaps the default isn't really "next", even though that's what the accessory button displays
Ron T.
I'll do more research on those options. Thanks. I'm done for tonite!
Mark M.
OK
if anyone comes up with a question, chime in
Ron T.
has left the room
Gene
Thanks Mark. I've gotta run.
Gene
has left the room
Scott
is method onDestroy() always called when an activityisdestroyed ?
Mark M.
if it is actually destroyed, yes
however, bear in mind that activities might not be destroyed
if you crash, you will not be destroyed
Scott
even power off button ?
Mark M.
if your process is terminated due to a Force Stop, you will not be destroyed
if the user fully turns off the device, I don't know quite what happens
I *think* Android shuts the processes down gracefully and you will be destroyed, but I am not 100% certain of that
Scott
ok, thanks
Mark M.
it also feels like the sort of area where device manufacturers might tinker and alter the behavior
Scott
i'll test some scenarios
7:55 PM
David
I put database.close() in onDestroy, but sometimes errors appear that database is not closed. How can I fix the db error?
Mark M.
I don't know
perhaps you are opening the database twie
er, twice
David
I will check. Another question.
After I stopped the app, after sometime, it automaticaly restart.
How can I make the app stay stop?
Mark M.
what do you mean by "stopped the app"?
David
While the app is running, go to home page.
Mark M.
you did not stop the app, then
you brought up the home screen activity
David
You are right.
Mark M.
your app is still running, just not in the foreground
David
why restart? It seems run onCreate() again. It doesn't stay where it was.
Mark M.
it did not "restart", because it was not stopped
8:00 PM
Mark M.
if you are saying that while your device/emulator is sitting at the home screen, your activity spontaneously returns to the foreground, you called startActivity() on it
David
Sorry. For example, I moved the listView and when the app run, the ListView shows the first items.
Mark M.
Android does not bring activities to the foreground on its own -- something is the trigger
David
Will the Service running background?
Mark M.
I am sorry, but I do not understand that question
David
In my app, there are two services.
Android Service.
If something triggers the app, I will investigate.
Koen H.
has entered the room
David
Thank for your advice.
Koen H.
Hello
David
has left the room
Mark M.
howdy, Koen!
Koen: do you have a question?
8:05 PM
Koen H.
well ... have to think about it ... just realised the chat was going on, so I just came in to have a look what the other conversations were about.
Mark M.
ah
unfortunately, Campfire does not let you scroll back to stuff that was discussed prior to your joining the chat
Koen H.
Don't know what's been talked about
Mark M.
this is a Q&A facility
Koen H.
but I do have sort of a question
Mark M.
go right ahead
Koen H.
eum, but how do I formulate it ...
the situation:
I have a note app
(b-noted)
now, I'd like to start making other apps
let's say a lists (db) app
Now I was thinking to make a separate app that will support all these apps
That one I would name b-services
Mark M.
what do you mean by "support all these apps"?
Koen H.
and would actually do all the background stuff
make connection with services on the internet (Google API's)
maintain the databases (the local ones)
keep track of alarms
Mark M.
that sounds like fairly essential functionality for each app
why would the user want to get any of your apps without that functionality?
Koen H.
well, that is the question ... is it a good idea to put all that functionality in that separate app
Mark M.
not if it means your "real" apps are useless
Koen H.
the moment you install one app, you NEED that 2nd app
Mark M.
yeah, users will get frustrated with that
having plugins for optional features is cool
8:10 PM
Koen H.
and if you only use one app, it's kind of ... well ... frustating
Mark M.
agreed
Koen H.
but when you have 2 or 3 of those apps, it starts being handy
Mark M.
why?
Koen H.
all data is together, and can thus be easier to use it as a whole
another example
I also have some Locale-plugins
using a 3rd app could function as the "licensing" hub
for all the other apps
Mark M.
again, why would the user want that?
with in-app purchasing, you should need zero apps to be able to upgrade from free to paid
Koen H.
well, as it is now: in those plugins I have InApp to get a license
but: you need to buy them separatly
but some of these plugins work in combo
so I want to give those users a discount if they buy the 2 of them
which I now can't do
Mark M.
sure you can
Koen H.
? how ?
Mark M.
your code can use PackageManager to see what other plugins are installed
you use in-app purchases to buy the combo license
from *either* of the apps
Koen H.
crap
so simple
Mark M.
and the app that did the purchase tells the other app "yo! you're licensed!"
Koen H.
never thought about it :)
Mark M.
the notion of a centralized app is perhaps a bit easier for *you*
8:15 PM
Mark M.
but if it adds barriers to adoption for the user, that's not necessarily a good thing
Koen H.
actually I got to the idea of that b-services because of those plug-ins
do you know Locale?
Mark M.
I know of it, but I have not used it personally
I know it is heavily based on plugins
Koen H.
you have "condition" plug-ins, and "settings" plug-in
a bit like "if" and "then"
if = condition
Mark M.
right
Koen H.
then = setting
but you can forward info from the first to the second
you can't I mean
so, I was thinking: I'll install a service which temporaly stores that info, and make it available to the second (setting) plugin
Mark M.
you mean, literally for Locale?
or is this for your own plugins for your own app?
Koen H.
yeah
Mark M.
ummm... yeah to which? :-)
Koen H.
no, for my plug-ins, for Locale
Mark M.
so long as it is only for your plugins, that's OK
Koen H.
an example: I have a call monitor plugin which allows you to trigger a condition based on a certain phone number
Mark M.
I worry about privacy issues if you were going to try to be an intermediary for arbitrary plugijns
er, plugins
Koen H.
but in my settings plugin, I have no way of seeing which number that is
so I want to have something that stores and forward that information
8:20 PM
Koen H.
so I got to the idea of making a service for that
and then I thought, hey, why not put other services available in that "service" for my other apps
but I don't know whether it's a good decision in the long term
Mark M.
well, I can't really tell you "long term", since I'm not you
if your plugins are useless without this other app, it will depress interest in those plugins
Koen H.
well, in the long run, I would like to create a "suite" of apps
that are more or less "connected"
Mark M.
suites are fine, if they are distributed as one big app, or are loosely coupled
Koen H.
notes with lists that eventually can be used in my plug-ins and vice versa
Mark M.
tightly-coupled suites, where users are forced to install N apps to use 1 of them, will be annoying
Koen H.
ok
Mark M.
particularly since Android lacks automated dependency management (a la apt or yum for Linux)
Koen H.
but how would you do it then, when you want to bundle some core functions so I don't have to put that code in each app separatly?
Mark M.
you *would* put that code in each app separately
perhaps using an Android library project to reduce code duplication
Koen H.
ok
Mark M.
again, if they are separate apps, you really need to allow users to uninstall or install them at will
Koen H.
ok, I get that
but,
Mark M.
if you want them tightly-coupled, make them one app
8:25 PM
Koen H.
what do you think f.e. of the GO store, which sells all kinds of extensions for the various apps they have
is that a good idea, or would you put them in their respective apps?
Mark M.
I have no idea what "f.e. of the GO store" is
Koen H.
you know the GO products : GO Launcher, GO Sms, GO weather, ....
Mark M.
I don't use any of them
I recognize a couple of those by name
Koen H.
all of them are skinnable
Mark M.
skins are not essential, so a plugin model is fine -- the apps presumably can work without downloading a separate skin
Koen H.
and they sell skins in one store, allthough skins for GO Launcher don't work f.e. with GO Sms
Mark M.
"f.e." == "for example"?
Koen H.
yep
Mark M.
ah, that helps
Koen H.
a bit like I have already now:
b-noted is free
Mark M.
the store itself, presumably, is optional -- you should not need to download the store to use any of the individual GO apps
Koen H.
ok, as long as it's optional, it's a matter of personal preference
Mark M.
right
Koen H.
if it's not optional, then it's better to put it in the app itself
Mark M.
right
Koen H.
so, back to my situation:
b-noted is free,
but to get the pro version, NOW, you have to download b-licensed, which is not free and tells b-noted it's now registered
that is actually NOT as it should be?
8:30 PM
Mark M.
that's a classic solution
before in-app purchases
Koen H.
you think InApp is better now?
Mark M.
now, I would assume that developers looking to do free->pro would tend towards in-app purchases
it beats maintaining two separate APKs
Koen H.
yep :)
Mark M.
it also consolidates your downloads, which should help with rankings
Koen H.
and how about a plugin for that?
would that be something?
Mark M.
a plugin for what?
Koen H.
for payment
Mark M.
then you're back to your current model, for all intents and purposes, albeit possibly one central "plugin" for the suite
I don't know what that buys the user over in-app purchaes
er, purchases
particularly when it comes to getting users to part with their money, EASY is the watchword
Koen H.
well, again it's a bit to separate that code, which makes it easier to maintain on my side
Mark M.
*any* barriers -- like forcing them to download another app -- reduces conversion rates
Koen H.
also because I want to make other payment methods possible (pay-pal, etc)
ok
Mark M.
that's a wrap for today's chat
Koen H.
alright
Mark M.
there's another one tomorrow at the same start time, 7:30pm Eastern
Koen H.
thanks for the chat!
Mark M.
have a pleasant day, all!
Koen H.
maybe tomorrow with more technical questions :)
TX
Scott
has left the room
Koen H.
has left the room
Mark M.
turned off guest access

← Thursday, March 29

 

Office Hours

People in this transcript

  • David
  • Gene
  • Koen Hoorelbeke
  • Mark Murphy
  • Ron Thomas
  • Scott