Oh, I didn't know that. The API docs do not mention that. Thanks for
the info!
On May 27, 2:59 pm, Kostya Vasilyev wrote:
> It's just a shortcut:
>
> public final void runOnUiThread(Runnable action) {
> if (Thread.currentThread() != mUiThread) {
> mHandler.post(action);
Thanks for the links. Your code clarifies things a lot.
Thinking about Handler/HandlerThread made me wonder about something...
Activity class provides a method called runOnUIThread(), which seems
to me a very straight-forward way to execute commands emanating from
other threads, on UI thread. Is t
Java
> wrapper of the back-end thread, and associated with that thread.
>
> Take a look at HandlerThread, that's the basic idea for your backend, except
> you'd be calling a native method for processing messages.
>
> -- Kostya
>
> 2011/5/26 Oceanblue
>
> >
I have an interesting design challenge:
I have a frontend(Activity) and a backend (written in native C/C++)
code. The backend is a complex object which partially controls the
flow of application & once started runs in it's own thread. So I have
a "distributed control" scenario.
The Activity needs
As I am externalizing all possible user-prompt & error strings, the
strings file is becoming pretty big. The aim of course is to keep
future localization in mind.
Is there a limit or a best-practice standard to how many strings
should be put in resources? Will the performance degrade after a
certa
> > > Does it have any negative side effects?
>
> It might shorten the lifespan of the screen, or at least the
> backlight, but I don't know how long those are supposed to live.
> Otherwise, I can think of no particular issues.
I was basically thinking of a screen burn-in type of problem. I looked
@Mark Murphy: Thanks for the detailed answer.
I'll dig more into some of the options you have suggested.
On Mar 18, 10:16 am, Mark Murphy wrote:
> On Fri, Mar 18, 2011 at 10:56 AM, Oceanblue wrote:
> > I have a specialized application. This is for internal-use only and
>
I have a specialized application. This is for internal-use only and
not for public release. It does extensive image processing within an
AsynTask & updates a progress bar on screen to keep the user informed
as to where it is at. Since it's thousands of images, the application
might run for hours, e
gcstang, I need to get the MAC address from the NDK layer, so I used
the socket call:
s = socket(AF_INET, SOCK_DGRAM, 0);
I have a Motorola Driod, but hopefully in a few days, I'll be able to
check this code on other phones too.
On Feb 16, 10:56 am, gcstang wrote:
> What did you use to
Thanks for your input Brad.
I've decided to go with MAC address for now. I tested with my device
with wi-fi switched off & in Airplane mode & I was able to retrieve
the MAC address (using Android API) in both cases. Hope this is the
right choice.
On Feb 15, 12:19 pm, Brad McNeiL wrote:
> Just a
Hi Narendra,
Thanks for your answer.
Could you please elaborate on your reasons for preferring MAC address
to ANDROID_ID (in android.provider.Settings.secure)?
Thanks!
On Feb 14, 1:00 am, Narendra Bagade wrote:
> Mac will be best option for unique representation of devices
>
--
You received
Like a lot of other applications, my application has different levels
of features access. Depending on the unique device ID, it switches on
certain features (paid/licensing issues). This feature switching on-
off is already done in existing native C/C++ code for all kind of
mobile devices/PCs etc,
12 matches
Mail list logo
