Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by Muhammad Muslih » Fri, 05 Mar 2010 07:47:07 GMT


Sponsored Links
 karena saya udah pake Halo, ya terpaksa pake Flash. soalnya ribet kalo bawa
hape lebih dari 1 :D

-- 
"



Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by Timmy Gunawan » Fri, 05 Mar 2010 09:44:39 GMT


 Xl mah parah.. tp uda terlanjur nomer utama sih hehe..

m
|simply Mgc




karena saya udah pake Halo, ya terpaksa pake Flash. soalnya ribet kalo bawa
hape lebih dari 1 :D



-- 
"


Sponsored Links


Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by riswan christianto » Fri, 05 Mar 2010 09:46:38 GMT


 Wkwkwkwkwk ntar dikejar wiwieth loh




Xl mah parah.. tp uda terlanjur nomer utama sih hehe..

m
|simply Mgc





> "



Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by Dede Ardian » Fri, 05 Mar 2010 11:26:28 GMT


 *siul-siul di pincak*

2010/3/5 riswan christianto <berrii...@gmail.com>






-- 


rgds,
wongompong
dede ardian

-- 
"



Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by Trisno Hadinoto » Fri, 05 Mar 2010 13:00:20 GMT


 Bos reza betul kata bos dantez, semua tergantung tempat dipakainya. Apabila
bos reza bisa pakai paket matrix broadband didaerah nya maka ini kesempatan
untuk segera mengambilnya. Karena matrix broadband hanya keluar pada waktu
pameran ini saja dan itupun tiap kota hanya dikasih jatah keluarnya, Kalau
disurabaya setau saya hanya 300 kartu yang dikeluarkan.
Paket yang ditawarkan ada 2 dari matrix broadband :
1. Paket 90.000 dengan kapasitas 500 mb
2. Paket 175.00 dengan kapasitas unlimeted.
Mungkin bisa jadi bahan pertimbangannya bos reza.

*saya bukan orang indosat, waktu kemarin lihat dipameran dan dapat infonya
begitu.....

2010/3/5 dantez <blepe...@gmail.com>



-- 
"



Paket Data Internet Apa Kira-Kira yang Cocok Buat Android? IM3, XL ato Simpati?

by Muhammad Muslih » Fri, 05 Mar 2010 14:00:36 GMT


 barusan apply Flash Basic yang corporate cmn 100rb

-- 
"



Other Threads

1. Non-parallel construction of DatePicker and TimePicker

I was surprised and dismayed to discover that the DatePicker and
TimePicker classes, which are of parallel construction in almost every
way, differ in one significant way.  There is no
setOnDateChangedListener(...) method in DatePicker while there is a
setOnTimeChangedListener(...) method in TimePicker.  For two classes
that parallel one another in every other way, including the appearance
and operation of their corresponding Views, why do they diverge in
this fairly important aspect?   I eventually discovered that there is
a way to set the OnDateListener through the init(...) method, but COME
ON!  Was this just an oversight on Google's part?  I hope that they
fix this in a coming release.

-- 

2. GPS code works in HTC machines but fails in MOTO's

I think his use of the main Looper is OK -- though not something I
would endorse, in part, because:
I think the problem is in the lifetime of his handlers.

Yidongsoft:

Normally, you allocate the Handler in your main thread -- and then
HANG ONTO THEM, generally in an instance field of your Activity or
Service. They'll pick up the main looper automatically if you create
them in the main thread.

Now, I don't know for sure that a Handler doesn't install some strong
reference to itself in the Looper. But I would expect it to only
install a weak reference -- that means, the GC will throw away the
Handler -- and its code -- sometime after you exit each of your
methods.

If this is hypothesis is correct, the reason you see different
behavior is likely that the HTC devices you're considering (such as
the Nexus One) have more RAM than the Moto DROID, which only has 256
MB. So things get GC'd quicker.

I'm not going to go read the code to find out, because there's a
pattern I see no need to deviate from:

* Create your Handler in the context of whatever you want to associate
with handling it. For example, if you're updating a view in an
activity, create it in the onCreate() method for the view.
* Save your handler in an instance variable in that context. In other
words, the Handler is owned by the context in which it runs, not the
context in which messages are posted.
* When you run some code in some other context that wants to post back
-- pass it the Handler, so it can do so. (Often this will be from code
from the same class -- you can just refer to the instance variable).

Try changing your code to work that way, and see if it works better.

I'm not going to look, because I base this guess on long experience
designing frameworks like this. And it's how I would do it. You WANT
your posted code to go away, if the Handler is no longer needed before
it gets to run. Actually, I'd be even MORE aggressive on the point,
and not give you any direct access to the Handler, and make you queue
it up via the object with which the Handler is associated -- e.g. an
Activity or Service.

Even if I'm wrong -- you don't want to write your code that way --
handing important information to an object for later use, and then
just letting go of it. If coding that way doesn't get you into trouble
here, it will somewhere else. And even if it doesn't get you into
trouble directly -- when you get in trouble with something else,
you'll look at this code, and NOT KNOW whether you have this problem
or not.

So regardless of whether this is your bug or not -- it's Bad Practice.
Or to put a more positive spin on things: It's Good Practice to
associate a Handler with the context in which things are being
Handled, and initialize them with that object, in the same thread.






-- 

3. Harga Nexus one

4. OOT : miring gak jadi dulu

5. File system access triggers / listener on Android devices

6. Debian on NexusOne woow

7. Hello all + WTA gmail attach