It really depends on what you want.
In my app, the request to the server is made first. If this is successful
(connection is OK, login is OK), then the data from the server is assigned
to an Intent and this Intent is used to start an Activity to show that
data.
If the connection is wrong, a d
On Apr 28, 3:28 pm, Streets Of Boston wrote:
> It really depends on what you want.
>
> In my app, the request to the server is made first. If this is successful
> (connection is OK, login is OK), then the data from the server is assigned
> to an Intent and this Intent is used to start an Activit
I parse the data from the service into data that can be persisted.
If the data is small enough, the data is translated into a class that
implements Parcelable. This parcelable is then assigned to the Intent that
starts the Activity (using 'Extras'). When the process is killed and the
user goes
On Apr 28, 3:43 pm, Dianne Hackborn wrote:
> Another way you can approach this is to have a singleton that arbitrates
> access to the service -- it binds through the application context, and has a
> reference count of the current activities using it, to know when to unbind.
> (If you care about
On Apr 28, 3:46 pm, Streets Of Boston wrote:
> I parse the data from the service into data that can be persisted.
>
> If the data is small enough, the data is translated into a class that
> implements Parcelable. This parcelable is then assigned to the Intent that
> starts the Activity (using 'E
Yes and no.
As long as your Extra in the Intent implements Parcelable properly, it
works. Calling getIntent() in onCreate or in onNewIntent gets you the data
that was used in the Intent that (originally) started the Activity.
If the user interacts with the Activity and thus *changes *the origin
On Apr 28, 12:43 pm, Dianne Hackborn wrote:
> On Thu, Apr 28, 2011 at 3:31 PM, Eric wrote:
> > In addition, my app has a large volume of data displayed in many
> > Activities, not just one set of server data / one Activity.
>
> Another way you can approach this is to have a singleton that arbitra
Shouldn't the OP also consider implementing all data access over the
net with a ContentProvider and then using a managed Cursor to access
it? It seems to me that would remove the need to frequently check for
null, since the managed Cursor will manage many of the lifecycle
issues for him.
On Apr 28
On Thu, Apr 28, 2011 at 3:31 PM, Eric wrote:
> How do you handle when user hits the HOME button, user leaves the app,
> Android kills the process, and they return back into that Activity?
>
That is why all activities that are using the service must at the least
support the case where they bind a
29.04.2011 0:01, Eric пишет:
The main thing I was asking about is, if the Service that the Activity
needs is not created and/or connected yet, should the Activity handle
that gracefully and watch out for NPE's, etc, or should the Activity
just shut itself down in favor of a temporary "Please wait
On Thu, Apr 28, 2011 at 7:04 PM, Doug wrote:
> > Another way you can approach this is to have a singleton that arbitrates
> > access to the service -- it binds through the application context, and
> has a
> > reference count of the current activities using it, to know when to
> unbind.
> > (If y
11 matches
Mail list logo