hello, EGHDK

how can I help you today?

Hey Mark, a few quetions today. first question I have is on ArrayList and concurrent modification exception. If I loop through my ArrayList, and I call remove on one of the items... why do I get a ConcurrentModificationException. I'm not modifying multiple things concurrently...?

something else is working with the ArrayList at the same time, apparently, such as iterating over its contents

So iterating over contents is "modifying"?

no, removing one of the items is "modifying"

So how does that cause that exception?

in one thread, you call remove()

in another thread, something is iterating over the ArrayList at the same time

result: a ConcurrentModificationException

moral of this story: only have one thread work on the ArrayList at a time

So in this code snippet, there are two threads involved?

oh

no, there's one thread

however, you are iterating over the list and removing items from it

and that's not supported

Sorry. I wasn't clear with my ques. Probably should have started with the snippet =)

So am I crazy to say that a ModificationException would make more sense in that scenario? Rather than saying Concurrent? Because it sounds like multiple things are modifying the arraylist... when they're not.

Unless "iterating" over the list counts as modifying it?

take it up with the authors of Java

Okay. So I'm not going crazy though right. In that snippet... theres only one thing really modifying the arraylist... right?

correct

Okay.

you just cannot be modifying the ArrayList in the middle of an iteration loop

Great. Just wanted to make sure. So how does an Iterator work?

Does it just make a copy of the ArrayList?

I have not looked at the internal implementation of Java iterators

Okay. Thats all I need to know for that then. If you don't need to know it... neither do i. hahaha

Next question. I'm not getting push notifications all the time, but am thinking maybe its my gcm receiver.

I was thinking maybe wakefulBroadcastReceiver is necessary. from this SO post. http://stackoverflow.com/questions/26380534/bro...

that would be a good idea when using GCM

But I'm not doing a long running process... I'm doing everything I need in the gcm push on the main thread...

please don't

unless your work is extremely short, please use a background thread

where by "extremely short", I mean one millisecond or less

All I'm actually doing is creating a notification, and inserting it into the notification tray. Would it still be a good idea to use a WakefulBroadcastReceiver

that should be safe, assuming you are not doing any disk I/O or network I/O to get the data for the Notification

Nope. Once I get the push, I just say "Update available".

So that should be safe right? Because its not anything long running at all.

then you should not need WakefulBroadcastReceiver for that

correct

Do you happen to know if creating a notification requires the ui thread?

it does not

you can show() a Notification on a background thread

Gotcha.

Next maybe random question, but I saw a tweet from joshua bloch on twitter and was wondering if you could make sense of it for me. He said "DO NOT INSTALL A JRE (only JDK). Also remove the JRE from your mom's machine. Java in the browser died over 10 yrs ago." What does he mean by not installing the JRE. Doesn't installing the JDK also include the JRE?

it sets up a JRE, but only for command-line use, IIRC

I don't think it supports any in-browser Java (applets, etc.)

Oh. Gotcha. That makes sense. I just found it weird that this java guru was saying not to install the JRE, and I thought I was missing something.

Okay. Last question! that was quick. This question is about my build.gradle file. I want to essentially compare two values in my build.gradle and if they don't match I'd like to throw up a warning of some kind before I build (a pop up dialog?). Do you think that's possible?

um, you can probably raise an exception that fails the build, which will be reported in the Gradle Console like any other build error

bear in mind that Gradle build scripts are not always used from an IDE, so there is no GUI

So no way to have a pop-up right? If anything I can fail the build... or just output a message to the console "BUILD CONFIG FIELD MISMATCH" type of thing?

"So no way to have a pop-up right?" -- right

"just output a message to the console "BUILD CONFIG FIELD MISMATCH" type of thing?" -- yes, but if it is not a build error, you might not notice the message

BTW, GradleException is the general-purpose fail-the-build exception

e.g., throw new GradleException("Could not read version.properties!")

Okay. Any way to make sure it's like the very last thing thats output to the screen or the very first thing?

it will always be pretty close to the last thing

Okay. Mark. Great. Thanks for all the info. You are a life saver!

you are very welcome

hello, Bob!

Hi Mark!

Bob: EGHDK has asked a few questions, so it's your turn -- how can I help you today?

I have a question about thread boundaries and interactions between logical boundaries.

If I call startActivity from a Service or even better a thread within a Service what is the impact and risk if any?

you risk users attacking you with torches and pitchforks for interrupting them, unless you're *real* sure they want you taking over the foreground

also, you will wind up creating a new task

otherwise, there's no risk

OK, I'm talking about within my own app of course. So tell me more about tasks in android and also is there a better way (is it bindings?) for communicating between the two?

at a very high level, tasks control the back stack

you don't communicate between tasks

starting an activity from a service requires that you put FLAG_ACTIVITY_NEW_TASK as a flag on the Intent

and the default behavior of that will be to put a new instance of the activity you are starting into a new task, so it starts its own back stack

you can use manifest entries (e.g., launchMode) to attempt to control this somewhat

So here's a scenario...user logs into app backed by Restful service, these creds are required for a background service to make use of Rest api for background. In the even that credentials are somehow changed in a way that requires user interaction, user is presented with login activity

...in the event I mean

your life will be in jeopardy if you do that

raise a Notification instead

and have the user launch an activity from the Notification to log in again

I like that, and will try to sell that idea. Not sure customer will take it though. Other options/ideas?

bulletproof vest?

With NSA watching us, I'm not sure I should comment on the possibility of vesting.

(lol)

I mean, seriously, interrupting the user in the middle of their game/video/turn-by-turn nav session is not going to be popular

particularly if the interruption means that they miss a game turn, plot turn, or left turn

This is more like a forms type of tool. Customer may want user locked out to protect proprietary information. Basically force out user but in a way that still retains app focus.

sorry, but that didn't quite parse for me

saying that the user has to log in again is perfectly reasonable

saying that the user has to log in immediately, regardless of what the user is doing with the device, is where the problems come in

so, prompting them that they need to log in (for background purposes) via a notification is fine

So, if credentials are locked out by administrator (Restful service) and the service fails to get a session how should I force logout?

...second service meaning android Service...

null out the authentication credentials in your process or something

I don't know much about your app

OK...so you think the app should check credentials as a part of user flow...like opening a new activity, requests, receive data, etc.

oh, absolutely

your process can cache that state, and revoke it as appropriate (timeout, server says "nuke it", etc.)

but bear in mind that your background work may involve a fresh process

Right ok...have done that before...for that type of work do you like using Google Accounts manager

if your process was terminated along the way while you were not in the foreground

I have avoided the Android authentication engine, just because of the roster of scary permissions it needs

...so I was going to address that by using a regular Service with restart flag and then using a thread from the Service.

(autorestart)

...hmm ok so homespun auth is your suggested approach then?

...auth and accounts I mean

again, I don't know enough about your app

but if I were writing something like this, I would lean towards "homespun", as you put it

ok...std disclaimer received. Thanks very much for the help. I'll yield back in case others are chompin on bits

EGHDK: do you have a question?

Bob: if you have another question, go ahead

ok -- regarding notification services

So, historically services like urban airship, et al. have been useful for creating push messaging. And I've not had alot of experiences with the google push service. What are you suggesting these days for apps that pester people with notifications ;-) (lol -jk)

...I get asked to build these often sadly

well, most of the services like Urban Airship use Google Cloud Messaging (GCM) under the covers

have you had a chance to try setting up an GCM stuff?

simply because trying to roll your own will be unreliable and/or battery-intensive

I have a chapter on GCM in the book

though it needs an update

ok -- so, in comparison to the pain of iOS Push is GCM fairly reasonable to setup?

I have never worked with iOS, so I have no basis for comparison

GCM is not that difficult to get going, though

ok -- i'll check out the chapter. Here's another...

I'm interested in putting in some ecommerce elements to some apps of choice...what are some of the easiest android integrations for this goal? Simple credit card.

beats me, sorry

haven't looked into this area

no prob...I'm assume google wallet has something so thought it relevant, but maybe they don't

ok thanks

and that's a wrap for today's chat

the transcript will be posted to https://commonsware.com/office-hours/ shortly

the next chat is Thursday at 9am US Eastern

have a pleasant day!