Office Hours — Today, October 8

← Saturday, October 5

Oct 8
7:20 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:30 PM
Ed
has entered the room
Mark M.
hello, Ed!
how can I help you today?
Ed
Hi Mark! Good evening
I always feel like I bug you... :-). but thanks for your time
7:35 PM
Ed
so I have a legacy Android app
mykeystore2.keystore is in the legacy folder for the app
but I don't know any of the passwords... am I SOL ?
Mark M.
um, perhaps
Ed
worse case... I make a new file and legacy users will have to delete the old app to install the new app correct ?
Mark M.
not exactly
you would not be able to publish the app under the same application ID
Ed
I have full access to the legacy PlayStore Account
Mark M.
so the users could have both apps installed at the same time
Ed
management wants to have this show up as an 'upgrade'
Mark M.
that's not possible without the keystore password
an upgrade requires the same signing key and the same application ID
you have the latter, not the former
Ed
perfect! I'll break the good news tomorrow. :-)
Mark M.
I have heard of people trying to brute-force the password -- not sure how well that works
Ed
good to know
I have a LiveData question for you....
Mark M.
and, if it is a matter of somebody knowing the password and not being willing to give it to you, you can always use a $5 wrench: https://www.xkcd.com/538/
(note: this may be illegal in some jurisdictions)
7:40 PM
Ed
the developer had all of this on his laptop... and the rookie deleted his user account when he got his machine
I literally went dumpster diving
Mark M.
ummm... no backups?
Ed
then had to reverse engineer the APK from the Google Play Store to get the legacy code
Mark M.
oboy
Ed
the git repot was from 2015
the APK version was 2017
I was able to get it all working...
know maybe you know why my URI versus File issue wasn't as big a deal to me... as it was to you? :-)
Mark M.
because it's going to fail on a variety of devices
Ed
thanks for that extra e-mail... and URI Retrofit patch... I'll be using it in 2020... I have an iOS app to ship after this is done
Mark M.
no problem
Ed
I actually have it working on Android 10 and all other API devices
with a minor change
Mark M.
not for any possible Uri, and I'm not certain where you get the Uri values from
Ed
View paste 
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="${applicationId}.provider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/provider_paths"/>
        </provider>
Mark M.
that's you supplying Uri values to another app
my concern was your attempts to convert a Uri to a filesystem path
7:45 PM
Ed
View paste 
    private void startTakePictureIntent() {
        Intent takePictureIntent = new Intent("android.media.action.IMAGE_CAPTURE");
        takePictureIntent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
        if (takePictureIntent.resolveActivity(getPackageManager()) != null) {
            File photoFile = createImageFile();
            Uri uri = FileProvider.getUriForFile(ShareActivity.this, BuildConfig.APPLICATION_ID + ".provider", photoFile);
            if (photoFile != null) {
                mCurrentPhotoFile = photoFile;
                tempFilePath = mCurrentPhotoFile.getAbsolutePath();
                takePictureIntent.putExtra("output", uri);
                startActivityForResult(takePictureIntent, REQUEST_IMAGE_CAPTURE);
            }
        }
    }
Mark M.
that's fine, other than the unreliability of ACTION_IMAGE_CAPTURE implementations
Ed
android:requestLegacyExternalStorage="true"
Mark M.
you wouldn't need that for FileProvider
Ed
I agree, I'm moving it to CameraX next year... just trying to put that fire out
Mark M.
hopefully the fire wasn't in the aforementioned dumpster
Ed
lol
I have a LiveData question for you... if you have time
Mark M.
I have > 40 minutes!
plenty o' time!
Ed
nice!
so I have 3 values that I want to persist
across app use
so when you load the options panel... it remembers your last values
Mark M.
by "app use", do you mean multiple processes over time?
Ed
it can 'default' on launch and then persists during the launch window....
it's a printing app
Mark M.
so far, this sounds like SharedPreferences or something along those lines
Ed
so as you send multiple docs... keep the same settings..... for each item to print...
that's what I was thinking... because it wasn't working the way I wanted it to
LiveData gets reset every time
7:50 PM
Ed
Android changed the preferences lately
Mark M.
LiveData is a lifecycle-aware in-memory data holder with an observer system -- it's not a persistent data store
Ed
but I just needed it to remember state across the lifecycle of a single Activity
I have an Activity that launches another Activity
Mark M.
OK, then I misunderstood your requirements
Ed
it's three variables
Mark M.
so, Activity A has some data, and you want to be able to repeatedly launch Activity B, do stuff there, finish Activity B, and return to Activity A and still have your data?
Ed
yes
and in A Activity I do this...
View paste 
    protected void onCreate(Bundle savedInstanceState) {
        Log.d(TAG, "onCreate()");
        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_share);
        ButterKnife.bind(this);
        initPager();
        handleIntent();
        // init object
        _printOptions = ViewModelProviders.of(this).get(PrintOptionsModel .class);
and the B intent is launched like this...
View paste 
    private void startPrintIntent(ArrayList<Uri> imagePaths) {
        startActivity(PrintActivity.newInstance(this, imagePaths));
    }
Mark M.
so long as this is all the same process, your viewmodel should be a reasonable in-memory vehicle for holding your Activity A data (whether you use LiveData or not in the viewmodel)
however, you mentioned ACTION_IMAGE_CAPTURE -- if you start a third-party app, and yours moves to the background, your process might be terminated while in the background
Ed
good point, I'm going to ditch the LiveData
7:55 PM
Ed
there is no rotation for this screen and it's an Activity
Mark M.
there are other types of configuration changes beyond rotation
Ed
true, but I'm hoping if I have a small static object that I pass around I will be OK
Mark M.
if by static you mean a static field, watch out for memory leaks, and that won't help if your process gets terminated
Ed
while Kotlin gives you the neat 'singleton' feature... I'm still stuck in Java for this app
it's a static pojo
and the getter... if null creates a new with the default value
Mark M.
if you mean a singleton lazy-created POJO, watch out for memory leaks, and that won't help if your process gets terminated
Ed
by memory leaks you basically mean... making sure I null references to it for Activity objects going away correct?
Mark M.
or, say, having a List<ReallyBigPieceOfData> and keep adding to the list
Ed
if I do shared preferences doesn't that just persist to the AppBundle file system?
that seems to be the best thing to do...
Mark M.
I'm not sure where AppBundle comes into play, but SharedPreferences are stored on the filesystem
8:00 PM
Mark M.
so, if you want your data to survive for weeks (e.g., return visits to print), that's a reasonable choice for small data
Ed
in my naive... mind... the APK/App bundle are all part of the file system for the app on the device
Mark M.
yes, though the APK is stored in a different part of the filesystem
Ed
I'm glad you write books. :-)
Mark M.
well, my poetry sucks, so...
Ed
but the short and to the point sarcasm is excellent
just this week... I read. "this sucks"
lol
Mark M.
yeah, well, I try to keep it light in spots -- programming books can get awfully boring
Ed
I agree
the thing I like about your books... compared to BigNerdRanch
you allow me to use your material as a reference, with small, concise and to the point examples
8:05 PM
Ed
so I can pull it apart, break it, put it back together again... and understand how it flows
BigNerdRanch forces me to make coding changes to ALL the chapters BEFORE... the current assignment... and then diff that... just to see the small item and the relationships
great for learning... sucks for reference
Mark M.
that's a bit more like my *Exploring Android*, or the tutorial chapters in *The Busy Coder's Guide to Android Development*
that approach has its place, but it's not ideal for all scenarios
Ed
did you watch the fireside chat for Google IO this year?
Mark M.
yes, a few months back
Ed
when the guy asked the question about wearables...
I was laughing so hard I almost spilled my coffee
he should have dropped the mic before walking away
Mark M.
sorry, I forget that one -- I'll have to rewatch it sometime
8:10 PM
Ed
0
26:14
guy basically pointed out that 'wearables' wasn't mentioned at all by anyone.... at GoogleIO
and nobody on the stage was from that group either
it's like they've dropped that entire product
Mark M.
yeah, they like throwing platforms at the wall and seeing what sticks
WearOS, didn't stick that well
Android Auto, doing OK
TV, given three tries, they're muddling along
Ed
part of me thinks Flutter.IO is Google trying to put a fire under the Android folks...
maybe I'm wrong
Mark M.
there may be an element of that
8:15 PM
Ed
the Android TV piece has it's core feature as mining data of what people watch and feeding it back to the TV manufacturers
Mark M.
yes, though TV manufacturers with their own smart TV environments do the same thing
Ed
that is too good of a revenue stream to not continue
Mark thanks being my lighthouse on the storm sea... :-)
Mark M.
um, you're welcome!
BTW, watch out for the rocks
Ed
if you have a long commute you should listen to Ed Snowden's Permanent Record on Audible.com... good one to listen to
lol
Mark M.
ah, didn't realize that was out in audiobook form
Ed
cheers and have a great evening!
Mark M.
you too!
8:30 PM
Ed
has left the room
Mark M.
turned off guest access

← Saturday, October 5

 

Office Hours

People in this transcript

  • Ed
  • Mark Murphy