Ada yg mau, 0814...ganti nama

by Henry Wiwiet » Mon, 12 Apr 2010 17:31:12 GMT

Sponsored Links
 Buat rekan yg mau pake 0814....saya punya mau ditutup saja.
Free of charge
Ganti nama hny di Isat Gading pd wkt yg sy tentukan.

Syarat ganti nama, cb cari tau sendiri ya krn sy ga tau.

Ini per bulan 175rb, FU 2gb
Nmrnya: 0814 1014 0444


Venomously Brilliant
Cyanogen Mod


To unsubscribe, reply using "remove me" as the subject.

Ada yg mau, 0814...ganti nama

by Henry Wiwiet » Mon, 12 Apr 2010 17:50:35 GMT

 Okeh...thread closed ya.
Bsk eksekusi.


Venomously Brilliant
Cyanogen Mod

Wah, terbukti ya Om ...
Memang posisi amat sangat menentukan prestasi.
Saya aja masih miara dua plat kuning ama merah, karena memang saling
melengkapi.  Tapi ya itu ...  sama2 unlimited quotanya, tapi amat sangat
limited speednya, hihi ...


2010/4/12 Henry Wiwiet <>

To unsubscribe, reply using "remove me" as the subject.

Sponsored Links

Other Threads

1. SMS Sent Listener

Is there a workaround to wiring up a listener for SMS messages sent?
The android.provider.Telephony.SMS_RECEIVED works great, but I cannot
find it's partner!



2. Preferred Activity-Service communication pattern

I would suspect this Activity-Service communication pattern is being
implemented in a variety of ways with good reason.  Either the
developer is a newbie and found a way that works (probably from Mark's
book) or else they are strategically searching for a solution that
works specifically for their use case.  I am a newbie looking for the
specific case!

My application needs to have a daemon-like thread running to collect
statistics.  I chose the Service here because it looked like it has a
lesser chance of being killed-- especially when conditioned with the
setForeground(true).  Perhaps I could replace the service with a
Broadcast receiver and store my statistics in an Application static
structure as Mark suggests.  My UI Activity *does* depend on the
collected statistics for presentation and that Activity can be killed
and resurrected any number of times without causing a problem.
However, if the Service is stopped, the application will miss events
that statics are beg compiled over and the application will
effectively become useless!  Does the Android Application lifecycle
support the notion of a daemon thread that will not get booted out of
memory?  I have read about lifecycles and precious resources and my
service is as skinny as they come.

What strikes me as odd is how on the one hand Android touts being able
to run background tasks when all the while you are encouraged not to
do it!

I am currently updating the Activity UI from the Service via a stashed
Handler in the Application scope.  Generally my design is as follows:

AppStatistics extends Application and contains the current Activity
instance and stats
public class AppStatistics extends Application {
    private PlanTrak planTrak;
    // internal statistics here
PlanTrak is my UI
public class PlanTrak extends Activity {

    Handler guiHandler;

    protected void onCreate(Bundle savedInstanceState) {
        guiHandler = new Handler() {
            public void handleMessage(Message msg) {
          // blah, blah, UI updates
        ((AppStatistics) getApplication()).setPlanTrak(this);

PlanTrakService is my aemonpublic class PlanTrakService extends Service {
     AppStatistics app;
    @Override public void onCreate() {
      // I read this is supposed to raise the priority of this Service
to minimize it being killed
    app = (AppStatistics) getApplication();

      // init the service here

    @Override public void onDestroy() {

    private void _startService() {
          new TimerTask() {
            public void run() {
      Log.i(getClass().getSimpleName(), "Timer started!!!");

    private void _monitorStats() {
      Message message = Message.obtain();

    private void _shutdownService() {
      if (timer != null) timer.cancel();


3. Dialog callback from withing callback?

4. Posts not appearing in group

5. emulator to run iphone apps on android

6. OpenGL and VBO buffers

7. Dialog Theme