Re: [android-developers] Re: Meta: Changes to new-user moderation policy

[Streets Of Boston]

True,

This place is now useless. 

Stackoverflow.com is where it's at...

On Friday, September 2, 2016 at 12:33:28 PM UTC-4, jtoolsdev wrote:
>
> This place is a mess anyway.  Like Trevor said Google+ developer groups 
> didn't work out.  They became social networking brag stations.  An actual 
> forum BBS would be better but perhaps Google doesn't have any such company 
> written software and they tend to suffer from the NIH syndrome.  With a 
> forum you could have sections for beginners, a section for each area of 
> interest and yes a jobs posting section.  History has shown forums work 
> better.
>
> On Thursday, September 1, 2016 at 12:36:23 PM UTC-7, Steve Gabrilowitz 
> wrote:
>>
>> Jason, the problem is that these scums keep changing their email - by the 
>> time an admin can delete their account they have already abandoned it and 
>> moved on to another!
>>
>> Only answer is to have active moderation where a moderator must approve 
>> all posts from a new account until the owner has "proven themselves".  I 
>> would also volunteer as a co-moderator, if we can get maybe half a dozen of 
>> us splitting the task then new posts could be approved fairly quickly.
>>
>> On Sep 1, 2016 3:10 PM, "Jason Atwood" <jason@stablekernel.com> 
>> wrote:
>>
>>> How easy is it to delete a spam account from the admin console? Single 
>>> button click? If it's easy, I'll volunteer to be an admin just to help with 
>>> the spam. If a few other people did this too I bet we could have it down to 
>>> zero in no time.
>>>
>>> On Wednesday, August 31, 2016 at 1:18:44 PM UTC-4, Streets Of Boston 
>>> wrote:
>>>>
>>>> Please, make this group moderated again or figure something out to weed 
>>>> out all the spam, rants and job-postings. 
>>>>
>>>> This group has been basically useless. 
>>>> Finding actual questions to answer is near impossible.
>>>> Posting your own question will get drowned out in a sea of spam a 
>>>> second later.
>>>>
>>>> Thank you,
>>>> --- Anton.
>>>>
>>>> On Monday, November 30, 2015 at 6:28:00 PM UTC-5, Trevor Johns wrote:
>>>>>
>>>>> *As of today, new members to this group are able to post immediately, 
>>>>> without being subject to moderator approval.*
>>>>>
>>>>> Previously, posts from new members to this group would be held for 
>>>>> moderation. However, with the addition of Stack Overflow and Google+ as 
>>>>> popular discussion mediums, it's been difficult to find volunteer 
>>>>> moderators. As a result, the moderation queue has been showing signs of 
>>>>> neglect -- which means that new posts just aren't getting through.
>>>>>
>>>>> To address this, effective immediately, I've removed the moderation 
>>>>> restriction for new members.
>>>>>
>>>>> While this means that some spam may get through, this is necessary in 
>>>>> order to keep this group functioning properly going forward. If you do 
>>>>> see 
>>>>> spam, simply report it through the Google Groups web UI. (Click on 
>>>>> "Report 
>>>>> Abuse" next to the "Reply" button.) For larger/urgent issues, you can 
>>>>> also 
>>>>> contact the group owners via email: 
>>>>> https://groups.google.com/forum/#!contactowner/android-developers
>>>>>
>>>>> -- 
>>>>> Trevor Johns
>>>>> Google Developer Programs, Android
>>>>> http://developer.android.com
>>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Android Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to android-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to android-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/android-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/android-developers/0e27c1a0-b710-4cdf-aea3-be48bd50b85a%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/android-developers/0e27c1a0-b710-4cdf-aea3-be48bd50b85a%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/89a8bce3-4f31-4dff-98b5-19dc0fe4392c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Meta: Changes to new-user moderation policy

[Streets Of Boston]

Please, make this group moderated again or figure something out to weed out 
all the spam, rants and job-postings. 

This group has been basically useless. 
Finding actual questions to answer is near impossible.
Posting your own question will get drowned out in a sea of spam a second 
later.

Thank you,
--- Anton.

On Monday, November 30, 2015 at 6:28:00 PM UTC-5, Trevor Johns wrote:
>
> *As of today, new members to this group are able to post immediately, 
> without being subject to moderator approval.*
>
> Previously, posts from new members to this group would be held for 
> moderation. However, with the addition of Stack Overflow and Google+ as 
> popular discussion mediums, it's been difficult to find volunteer 
> moderators. As a result, the moderation queue has been showing signs of 
> neglect -- which means that new posts just aren't getting through.
>
> To address this, effective immediately, I've removed the moderation 
> restriction for new members.
>
> While this means that some spam may get through, this is necessary in 
> order to keep this group functioning properly going forward. If you do see 
> spam, simply report it through the Google Groups web UI. (Click on "Report 
> Abuse" next to the "Reply" button.) For larger/urgent issues, you can also 
> contact the group owners via email: 
> https://groups.google.com/forum/#!contactowner/android-developers
>
> -- 
> Trevor Johns
> Google Developer Programs, Android
> http://developer.android.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/2eefba93-82f2-4b6a-8c48-b4dbf850be56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: Android Studio + Kotlin + databinding = unused methods?

[Streets Of Boston]

You're right, that could be an issue. 
When coding Java source, you can add comments to disable certain Lint 
checks. I know those work in Kotlin as well, but the set of available 
'comments' may be limited compared to their Java counterpart.


On Tuesday, May 17, 2016 at 10:46:37 AM UTC-4, Mike Hurley wrote:
>
> I just looked in Android Studio 2.1.1 and I didn't see an option to 
> "comment out" the unused method warning for that method. My only choice was 
> to clean delete the method. Is there a manual syntax/annotation I can try? 
> I wonder if the Kotlin plugin is simply less advanced in this area.
>
> On Mon, May 16, 2016 at 1:51 PM, Streets Of Boston <flying...@gmail.com 
> > wrote:
>
>> What about just disabling the Lint processing for this 'unused' issue?
>>
>> Click on the yellow warning and fix it by adding a lint-disabling comment 
>> to the method. This will remove the warning.
>>
>> On Saturday, May 14, 2016 at 10:47:33 AM UTC-4, Mike Hurley wrote:
>>>
>>> Here are the versions I'm using:
>>> Android Studio 2.1.1
>>> Kotlin 1.0.2
>>> Android databinding 1.1
>>>
>>> I currently have an annoyance in Android Studio with Kotlin and 
>>> databinding. A method bound to a button's onClick event is showing up in 
>>> the gutter as a yellow warning saying the method isn't used. Is this a 
>>> general databinding problem for all languages or is this an issue with the 
>>> Kotlin plugin? Are there any JVM or Kotlin annotations I can use to mark 
>>> the method as "used"? Any other ideas?
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/android-developers/mWI0KC7i5mQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> android-developers+unsubscr...@googlegroups.com .
>> To post to this group, send email to android-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/android-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/android-developers/f1604e76-1fdf-4932-bbaa-91bc9d707727%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/android-developers/f1604e76-1fdf-4932-bbaa-91bc9d707727%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/e4d6a89b-b251-492b-8af4-e009d5c6bfd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android Studio + Kotlin + databinding = unused methods?

[Streets Of Boston]

What about just disabling the Lint processing for this 'unused' issue?

Click on the yellow warning and fix it by adding a lint-disabling comment 
to the method. This will remove the warning.

On Saturday, May 14, 2016 at 10:47:33 AM UTC-4, Mike Hurley wrote:
>
> Here are the versions I'm using:
> Android Studio 2.1.1
> Kotlin 1.0.2
> Android databinding 1.1
>
> I currently have an annoyance in Android Studio with Kotlin and 
> databinding. A method bound to a button's onClick event is showing up in 
> the gutter as a yellow warning saying the method isn't used. Is this a 
> general databinding problem for all languages or is this an issue with the 
> Kotlin plugin? Are there any JVM or Kotlin annotations I can use to mark 
> the method as "used"? Any other ideas?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/f1604e76-1fdf-4932-bbaa-91bc9d707727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: (beginner question) variables reset when I change device orientation?

[Streets Of Boston]

Hint:

Your Activity object is destroyed and then recreated on a rotation. This 
means that all your *new* Activity's fields have been set to 0/false/null 
again.
Read the documentation about the `onSaveInstanceState(...)` method and how 
this stores data in the `savedInstanceState` parameter of the onCreate(...).

On Tuesday, April 12, 2016 at 2:15:46 AM UTC-4, Jesse Clark wrote:
>
> I am new to Android development.  I am experimenting with making a simple 
> app that displays a number that increases by one when the Up button is 
> pressed and decreases by one when the Down button is pressed.  It works 
> correctly, except when I rotate the device from landscape to portrait or 
> vice versa, the number is reset to 0.  Here is the code:
>
> package com.example.jz.counter;
>
> import android.app.Activity;
> import android.content.Intent;
> import android.os.Bundle;
> import android.view.View;
> import android.widget.Button;
> import android.widget.TextView;
>
> public class MainActivity extends Activity implements View.OnClickListener
> {
> private int counter = 0;
> private TextView OutputViewObject;
>
> @Override
> protected void onCreate(Bundle savedInstanceState)
> {
> super.onCreate(savedInstanceState);
> setContentView(R.layout.activity_main);
> OutputViewObject = (TextView)findViewById(R.id.outputView);
> OutputViewObject.setText("" + counter);
> final Button buttonUp = (Button)findViewById(R.id.up_button);
> final Button buttonDown = (Button)findViewById(R.id.down_button);
> buttonUp.setOnClickListener(this);
> buttonDown.setOnClickListener(this);
> }
>
> @Override
> public void onClick(View view)
> {
> switch (view.getId())
> {
> case R.id.up_button:
> counter++;
> OutputViewObject.setText("" + counter);
> break;
> case R.id.down_button:
> counter--;
> OutputViewObject.setText("" + counter);
> break;
> }
> }
> }
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/82e379ef-d6d5-45b3-8b0d-880f25ec2db0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: listView get child items in a loop

[Streets Of Boston]

I assume your ListView has a ListAdapter (probably a BaseAdapter?).

In your Adapter's getView(...) method, you have a position parameter. The 
position is the index into your array-list of data that you'd like to show 
in the correct list-item-view. 

You get your data-item from the Adapter given the position 
(getItem(position)).
You create your view, if your convertView is not yet set. In that view you 
have your EditText/TextViews and you assign the data from the data-item to 
these views.
Use the method 'setTag(...)' of your list-item-view and set the data-item 
as the list-item-view's tag.

When you convertView was null, you had to create you list-item-view. When 
creating this, set a TextWatcher to your EditText that allows you to be 
notified when the user changes the text.

In your TextWatcher, get hold of the list-item-view of your EditText. Get 
the tag from the list-item-view (getTag(...) method) and that will be the 
data-item associated with that list-item-view. Update the changed text from 
the EditText in your data-item.

When saving the data to the server, get hold of you Adapter, use getCount() 
and getItem(...) calls to get all the data-items. It should contain the 
updated EditText texts.


On Friday, February 19, 2016 at 5:17:24 AM UTC-5, NIWEWE David wrote:
>
> Hi! I have been working on something for more than 2 days, but only met 
> roadblocks all around. 
> I have a listView that is updated by a JSON array from the server, Each 
> item is composed by 
> 3 TextViews where one is not visible to the user and a EditText that is to 
> be updated by the user. 
> What I want to do is when the user has finished inputting data in all 
> EditText in that list, loop through
> all Items of the listviews getting their values, put them into a Hashmap 
> array, change the hashmap 
> into JSON and send the JSON to PHP. All works very fine for the visible 
> Items on the screen. But 
> I have failed to get item visible when you scroll. Any help? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/afa64fb3-d08a-4e5b-8fe6-6eef7823f818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: save web page login credentials via webview in android storage

[Streets Of Boston]

You should NEVER store the users credentials (password) in 
SharedPreferences or anywhere else for that matter. This is very un-secure. 
At best, use Android's *AccountManager* facilities.

Back to your WebView question.

The WebView of your app gets access to a cache where it can cache the 
necessary data such as cookies. Methods that allow access from your *Java* 
code to this cached data are gradually deprecated and taken out.

If the HTLM login-page allows the user to save (part of) his or her 
credentials, it will be taken care off automatically (e.g. a small 
"remember my info" checkbox or something similar is shown and a cookie will 
store the necessary data).

In other words, the solution lies in the design and implementation of the 
HTML login-page(s). Don't do anything special in your Java code for 
remembering user-name and password. 
The only thing you may want to get out of the HTML login is the user's 
access or authorization token(s). If you use a embedded *WebView*, you can 
use the *JavascriptInterface* facilities for that.


On Wednesday, January 13, 2016 at 7:48:44 PM UTC-5, Pedro CLR wrote:
>
> *Basically I just have like 6/7 months of experience with Java, and 2/3 
> months of experience with Android...*
>
>
> I was asked, while in my internship, to develop a simple Android app that 
> allow access to an existing (and working) responsive web page.
>
>
> The idea is simple:
>
>
>- the page works with a login in order to access certain content;
>- the objective is that the user only needs to login just once;
>- the login credentials are to be saved locally in order for the user 
>to be automatically logged in next time the Android app is accessed.
>
> I understand concepts of session in web development, as well as working 
> with PHP and JavaScript.
>
>
> Now in Android I only know how to do this separatelly from a webpage 
> (login activity, saving credentials to SharedPreferences, etc), but this is 
> not what my employers want...
>
>
> I'm a little bit lost, because CookieManager was deprecated, as well as a 
> series of other WebView methods...
>
>
> *The app only needs to start the MainActivity with a WebView as only child 
> view of the main layout (e.g., a FrameLayout), and then everything else 
> must be managed in the webpage...*
>
>
> How can I do this? :(
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/0abbf57a-f90a-4271-bfd8-a72a195251f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: JSON parsing in Android

[Streets Of Boston]

Looks like the server is sending the escape character "\" as well all over 
the place.
This one needs to be removed basically everywhere, i.e. the server should 
send something like 
{"User":{"id":"5", "name":"Bob" ... ... ... "FirstYear"}}


On Wednesday, December 16, 2015 at 6:11:36 PM UTC-5, Mukarram Ali wrote:
>
> This is what I am receiving from server as a string:
>
> {\"User\":{\"id\":\"5\",\"name\":\"Bob\",\"dob\":\"1995-12-12\",\"gender\":\"male\",\"religion\":\"hindu\",\"email\":\"
> m...@gmail.com 
> \",\"phone\":\"123456789\",\"address\":\"azadnagar\",\"classid\":\"3\",\"section\":\"A\",\"roll_no\":\"1\",\"collegeid\":\"bt123\",\"loginid\":\"junior123\",\"profilepic\":\"picsjunior123\",\"collegename\":\"FirstYear\"}}
>
>
> And here is what I am doing to parse in android , sr is the received 
> string:
>
> JSONObject  jsonRootObject = new JSONObject(sr);
> //Get the instance of JSONArray that contains JSONObjects
> JSONArray jsonArray = jsonRootObject.optJSONArray("User");
> String name="";
> //Iterate the jsonArray and print the info of JSONObjects
> for(int i=0; i < jsonArray.length(); i++){
> JSONObject jsonObject = jsonArray.getJSONObject(i);
> name = jsonObject.optString("name").toString();
>  }
>
>
>
> Exception-stack trace is in attachment.
>
>
> 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/de3f08cc-b63e-4999-88da-088a0ecb986b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: how can I catch deadlock or hang of process?

[Streets Of Boston]

I don't know of an API that can help you figure out a deadlock for you.

However, this is what I do to figure out the objects on which a deadlock 
occurs.

-When the app deadlocks, attach the debugger (if it is not yet being 
debugged).
-Then hit the Pause '||' button on the 'Debug' tab.
-Then in the Debug window, you'll see a Debugger tab that contains a 
'Frames' and 'Threads' tab.
-Select the 'Threads' tab.
-All the threads in this tab are now paused and you can open them up to see 
the last statement they executed. The threads and objects that are in a 
deadlock will become obvious.

Of course, *why* it is deadlocking is then up to you to figure out and fix.


On Friday, November 13, 2015 at 6:12:29 AM UTC-5, Ju-hyun Park wrote:
>
> how can I catch deadlock or hang of process?
> When the application on android has some problems such as deadlock or hang 
> etc, I want to catch the event using API..
> What should I do?
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: handling data migration in android application upgradation

[Streets Of Boston]

Read this first
https://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html

In the onUpgrade helper you can execute SQL statements to add columns, 
add/alter tables, drop tables, etc., whatever your need is.
Here is some more info
http://stackoverflow.com/questions/14419358/confusion-how-does-sqliteopenhelper-onupgrade-behave-and-together-with-impor


On Thursday, November 5, 2015 at 5:07:54 AM UTC-5, Jags wrote:
>
> Hi All,
>
> I need to implement data migration in my app. I have an sqlitedb which is 
> synchronized to cloud. my problem is to find best way to handle data 
> migration on app update.
>
> my questions are below.
>
> - does my existing data and database get deleted on app upgrade ?
> - is it possible to invoke a method on successful installation / upgrade ?
> - is it possible to bundle an empty db with app in playstore ?
> - is it possible to change the database schema of existing db or i need to 
> create new db with new schema and migrate and delete old db ?
> - what is the best and google recommended way to handle this ?
>
> regards
> j
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android Studio unit testing useless

[Streets Of Boston]

The tests run fast. The building of the changed code is what takes way too 
long.

On Thursday, November 5, 2015 at 7:07:20 AM UTC-5, Paulo Morandi wrote:
>
> Hello,
>
> Here at our company we use Robolectric + PowerMock + Mockito for Unit 
> Tests and works really fine. It's fast and don't need the emulator or 
> device to run the tests. I think you should check this out. Of course, 
> still somehow slow to build (due the gradle build), but the run of tests 
> should be very fast.
>
> --
> Paulo Morandi
>
> On Wednesday, November 4, 2015 at 12:53:07 PM UTC-2, Streets Of Boston 
> wrote:
>>
>> I never found TDD easy, or even feasible, using Android Studio or even 
>> Eclipse.
>>
>> Most projects' builds take too long to to TDD effectively. If you can't 
>> check your code and run your TDD tests within a few seconds of hitting the 
>> 'run-tests' button, it is useless... alas
>>
>>
>> On Tuesday, November 3, 2015 at 10:11:47 AM UTC-5, Brill Pappin wrote:
>>>
>>> I've just filed a bug for Android Studio about how useless the unit 
>>> testing is. 
>>> It can take over a minute to execute a single test, which means you 
>>> can't easily use it for verifying your code, and it makes it impossible for 
>>> those of us who use TDD regularly.
>>>
>>> Anyone else who finds this annoying, I would appreciate you giving the 
>>> issue some love, in the hopes that it gets some attention:
>>>
>>> https://code.google.com/p/android/issues/detail?id=192585
>>>
>>> - Brill
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android Studio unit testing useless

[Streets Of Boston]

I never found TDD easy, or even feasible, using Android Studio or even 
Eclipse.

Most projects' builds take too long to to TDD effectively. If you can't 
check your code and run your TDD tests within a few seconds of hitting the 
'run-tests' button, it is useless... alas


On Tuesday, November 3, 2015 at 10:11:47 AM UTC-5, Brill Pappin wrote:
>
> I've just filed a bug for Android Studio about how useless the unit 
> testing is. 
> It can take over a minute to execute a single test, which means you can't 
> easily use it for verifying your code, and it makes it impossible for those 
> of us who use TDD regularly.
>
> Anyone else who finds this annoying, I would appreciate you giving the 
> issue some love, in the hopes that it gets some attention:
>
> https://code.google.com/p/android/issues/detail?id=192585
>
> - Brill
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: android mediaplayer notification

[Streets Of Boston]

Take a look here:
https://developer.android.com/reference/android/support/v4/media/session/MediaSessionCompat.html

And google (or go to StackOverflow) "MediaSessionCompat" for more info if 
you get stuck.

On Monday, October 19, 2015 at 7:20:23 AM UTC-4, Russell Harrower wrote:
>
> PLEASE HELP! I am not understanding how I get the mediaplayer to show in 
> the notification drop down box, I have read how-tos and all that and it is 
> not making sense.
>
> I have this so far
>
> NotificationCompat.Builder builder = new NotificationCompat.Builder( this );
> builder.setContentTitle(getString(R.string.app_name));
> //builder.setContentText(mNotificationTextEditText.getText());
> builder.setSmallIcon(R.drawable.rnotifivcaton);
> NotificationManager manager =
> (NotificationManager) getSystemService( 
> Context.NOTIFICATION_SERVICE );
> manager.notify(1, builder.build());
>
> Which just makes the app show in the notification area. Now I just need a 
> play and stop button.
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] webview load page in background

[Streets Of Boston]

WebViews are only rendered if they are attached (to the Window) and if they 
are not 'View.GONE'.
This means you have to add a WebView to your Activity's hierarchy somehow 
and either set it to View.INVISIBLE or set its alpha to 0 (make it 
transparent).

There are 'optimizations' in the WebView implementation that won't render 
contents until the WebView becomes 'visible'.

On Tuesday, September 22, 2015 at 3:44:20 AM UTC-4, Jags wrote:
>
> thanks, is it the only way ? i can not put it as content, because, there 
> is already a visible content (another list) i am replacing that content 
> with webview when required.
>
> i am surprised why content is not rendered when the webview instance is 
> not set as a content !
>
> On Tuesday, September 22, 2015 at 12:15:33 AM UTC+5:30, TreKing wrote:
>>
>>
>> On Mon, Sep 21, 2015 at 2:07 AM, Jags  wrote:
>>
>>> i see blank page, the page is not rendered. but when the setcontentview 
>>> is called before loadurl, (i.e it is visible), the page loads and renders 
>>> with a white flash.
>>>
>>> to avoid this white flas, i want to load it while it is not set as 
>>> layout content.
>>>
>>
>> Leave it as the content but set it to INVISIBLE, then show it once the 
>> content loads.
>>
>>
>> -
>> TreKing  - Chicago 
>> transit tracking app for Android-powered devices
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android Java Call getBytesFromFile() Fails

[Streets Of Boston]

The method *getBytesFromFile* is not a static method in *java.io.File*
It is a static method in *com.compoze.util.IoUtility*

On Friday, September 11, 2015 at 12:44:20 PM UTC-4, JediDroid wrote:
>
> I am using Android Studio and Oracle Java 8. I am trying to get all bytes 
> from a file and pass them to a byte array.
>
>
> It is my understanding based on the Oracle website, that the method 
> getBytesFromFile() is defined in the Java library import java.io.File.
>
> See: 
> https://docs.oracle.com/cd/E13218_01/wlp/compozearchive/javadoc/portlets25/com/compoze/util/IoUtility.html#getBytesFromFile(java.io.File)
>
>
> I should be able to call the method in my code. 
>
>
> But I get the error message:
>
> cannot resolve method 'getBytesFromFile(java.io.File)'
>
>
> Why do I get the error message?
>
>
> It looks like it does not see import java.io.File.
>
>
>
> import java.io.File;
>
>
> // Read the recording.pcm file from storage.FileInputStream recordingFile = 
> openFileInput(recording.pcm, Context.MODE_WORLD_READABLE);
> recordingFile.read(string.getBytes());
> recordingFile.close();
> // NOTE: The code below gives error message: cannot resolve method 
> 'getBytesFromFile(java.io.File)'byte[] data = getBytesFromFile(recordingFile);
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android Studio NDK

[Streets Of Boston]

It is not (yet!) properly supported. But building your sources works well. 
Start here to figure out how. It helped me.
http://ph0b.com/android-studio-gradle-and-ndk-integration/ 


On Tuesday, June 16, 2015 at 1:19:20 PM UTC-4, MB wrote:

 Hi,

 I would really if someone could tell me where one can find official 
 documentation for using NDK with Android studio. All the samples and 
 documentation I've found on the website is for using NDK with eclipse. 

 http://tools.android.com/recent/usingthendkplugin

 Any pointers regarding this would be extremely useful.

 Thanks,

 --MB


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Receive Callback from Service

[Streets Of Boston]

Another option is to add a *ResultReceiver* ( 
https://developer.android.com/reference/android/os/ResultReceiver.html ) as 
a parameter to your AIDL function. This parameter can be used as a 
callback. The client (i.e. the one calling the AIDL function) will 
implement the parameter's *onReceiveResult* function, the server will call 
the *send* method on it.

On Saturday, April 18, 2015 at 2:18:03 AM UTC-4, abhi wrote:

 Is there any mechanism to receive a callback from service through AIDL 
 without any client intervention.Already i have implemented a two way 
 communication through AIDL, but still i couldnt figure out how to sent a 
 callback without a client call.Any insights into this will be very helpfull.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Is it possible, that Android kills a service inside an app?

[Streets Of Boston]

Oleksi: What do you mean by 'killed'? Do you mean that its 'onDestroy' 
method gets called?

Let's assume you are talking explicitly about starting the Service, not 
binding to it:

If a Service is started by some other component, it needs to be explicitly 
stopped, either by the same component, an other component or by the Service 
itself (stopSelf).
If the process contains both your Service and your components that can 
start or stop the Service, your Service's onDestroy will not get called. As 
far as I can tell, this would violate the contract between the user(s) of 
Service and the Service itself. 

When your Activity (app) goes to the background, the entire process could 
get killed at some point (especially, for example, if you have a Service 
running that uses a lot of resources causing your entire app to be resource 
heavy). But that means that both your Activity and Service get really 
killed (process killed) at the same time.

On Tuesday, January 6, 2015 11:49:50 AM UTC-5, Oleksii Bieliaiev wrote:

 Found some info here 
 http://stackoverflow.com/questions/8087596/when-service-is-killed-can-the-process-be-still-alive?lq=1



 On Tuesday, November 25, 2014 12:08:18 PM UTC+1, Oleksii Bieliaiev wrote:

 Hey guys,

 let's imagine we have an app with a service and an activity inside. Both 
 components live in a same process, our service is started (in terms of 
 Android) and a user does some interaction with an activity. Eventually our 
 app goes to background. My question is, whether is it possible, under 
 certain conditions (low memory, timeout, etc), that Android kills our 
 started service separately, without killing entire process?

 Thank you,
 Alex



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Is it possible, that Android kills a service inside an app?

[Streets Of Boston]

Oleksi: What do you mean by 'killed'? Do you mean that its 'onDestroy' 
method gets called?

Let's assume you are talking explicitly about starting the Service, not 
binding to it:

If a Service is started by some other component, it needs to be explicitly 
stopped, either by the same component, an other component or by the Service 
itself (stopSelf).
If the process contains both your Service and your components that can 
start or stop the Service, your Service's onDestroy will not get called 
until it is explicitly stopped. 
As far as I can tell, calling onDestroy out-of-the-blue would violate the 
contract between the user(s) of Service and the Service itself. 

When your Activity (app) goes to the background, the entire process could 
get killed at some point (especially, for example, if you have a Service 
running that uses a lot of resources causing your entire app to be resource 
heavy). But that means that both your Activity and Service get killed 
(process killed) at the same time.

On Tuesday, January 6, 2015 11:49:50 AM UTC-5, Oleksii Bieliaiev wrote:

 Found some info here 
 http://stackoverflow.com/questions/8087596/when-service-is-killed-can-the-process-be-still-alive?lq=1



 On Tuesday, November 25, 2014 12:08:18 PM UTC+1, Oleksii Bieliaiev wrote:

 Hey guys,

 let's imagine we have an app with a service and an activity inside. Both 
 components live in a same process, our service is started (in terms of 
 Android) and a user does some interaction with an activity. Eventually our 
 app goes to background. My question is, whether is it possible, under 
 certain conditions (low memory, timeout, etc), that Android kills our 
 started service separately, without killing entire process?

 Thank you,
 Alex



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Is it possible, that Android kills a service inside an app?

[Streets Of Boston]

Oleksi: What do you mean by 'killed'? Do you mean that its 'onDestroy' 
method gets called?

Let's assume you are talking explicitly about starting the Service, not 
binding to it:

If a Service is started by some other component, it needs to be explicitly 
stopped, either by the same component, an other component or by the Service 
itself (stopSelf).
If the process contains both your Service and your components that can 
start or stop the Service, your Service's onDestroy will not get called 
until it is explicitly stopped. 
As far as I can tell, this would violate the contract between the user(s) 
of Service and the Service itself. 

When your Activity (app) goes to the background, the entire process could 
get killed at some point (especially, for example, if you have a Service 
running that uses a lot of resources causing your entire app to be resource 
heavy). But that means that both your Activity and Service get killed 
(process killed) at the same time.

On Tuesday, January 6, 2015 11:49:50 AM UTC-5, Oleksii Bieliaiev wrote:

 Found some info here 
 http://stackoverflow.com/questions/8087596/when-service-is-killed-can-the-process-be-still-alive?lq=1



 On Tuesday, November 25, 2014 12:08:18 PM UTC+1, Oleksii Bieliaiev wrote:

 Hey guys,

 let's imagine we have an app with a service and an activity inside. Both 
 components live in a same process, our service is started (in terms of 
 Android) and a user does some interaction with an activity. Eventually our 
 app goes to background. My question is, whether is it possible, under 
 certain conditions (low memory, timeout, etc), that Android kills our 
 started service separately, without killing entire process?

 Thank you,
 Alex



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: onCharacteristicWrite Error Status 14

[Streets Of Boston]

I found this one here:
https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/android-4.3_r1.1/stack/include/gatt_api.h
 

It seems 14 means GATT_ERR_UNLIKELY, whatever that is ...


On Monday, December 8, 2014 11:34:30 PM UTC-5, Tony Pitman wrote:

 I am writing an Android app and using api 18 to do BTLE.

 I am able to connect, discover services and characteristics and read the 
 characteristic from the peripheral.

 When I try to write using WriteCharacterstic I get the onCharacteristicWrite, 
 but the status is 14. I can't find this status anywhere in the 
 documentation or anywhere else.

 The value does not make it to the peripheral. Can someone tell me what 
 this code means and why the value might not be writing?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Creating a custom-view with rounded corners

[Streets Of Boston]

Simple solution:
Use a FrameLayout and set the foreground drawable:
https://developer.android.com/reference/android/widget/FrameLayout.html#setForeground(android.graphics.drawable.Drawable)
 
The foreground drawable is drawn *over/on top of* the background and the 
children of a FrameLayout. 
If the foreground drawable is transparent in the middle and has the 
background color at the corners (outside the rounded corners), you may get 
the effect you want.

More tricky solution: 
Subclass the RelativeLayout into a class of your own and override the 
dispatchDraw method. Before calling super.dispatchDraw(canvas), set a clip 
path/region on the canvas (restore the canvas to its original state after 
the call to dispatchDraw). This will clip the drawing of its children. This 
clip path/region can define the rounded corners you want.


On Wednesday, November 12, 2014 5:54:02 PM UTC-5, dashman wrote:

 I've got a view that goes into a listview and would like each to have a 
 rounded corners.

 For the custom view layout, I set the parent to a RelativeLayout and
 and set the background to a shape - that sets rounded corners.

 RelativeLayout xmlns:android=http://schemas.android.com/apk/res/android;
 android:layout_width=wrap_content
 android:layout_height=wrap_content
 android:background=@drawable/bg
 
 
 But the problem is that if inside the view, if i draw to the edges - it 
 doesn't
 get clipped to the rounded corners.

 Any way to force that.




-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Tracking down multiple Activity instances in memory

[Streets Of Boston]

I had a similar issue once and I tracked it down to the View#setTag(int 
key, Object tag) method.
In my code, setTag was called with a tag value being an object 
holding/referencing an instance that had children referring to children of 
the View on which this setTag was called (tag was a 'ViewHolder' instance). 

Certain versions of Android implement setTag using a *static *map of 
WeakRereferences. This caused a View to never get garbage collected, since 
the tag would hold references to its children whose parents would then 
point (all the way up) to that View again. And if a View doesn't get 
garbage collected, its Context (i.e. Activity) would never get garbage 
collected.

Look if there is anything holding on to your Activity by the virtue of 
other instances being held through incorrect usage of WeakReferences.


On Wednesday, September 10, 2014 12:00:36 AM UTC-4, Nathan wrote:

 I'm fairly sure I have been able to use the eclipse tools before to track 
 down memory leaks - I even found one in Google Analytics. 

 But I can't for the life of me figure out.

 I have found out that there are two instances of Activity B in memory when 
 the activity is closed. I can see that with 

 I know enough to know that that is bad. 

 But what I cannot see is WHY. Why is that stupid activity still in memory 
 twice?

 I seem to remember that I right click on something and choose Merge Path 
 to GC Roots. 

 Then I get something like this. 


 Class 
 Name  
  
 | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap

 ---
 com.android.internal.policy.impl.PhoneLayoutInflater @ 0x42d2b0d8 
 Unknown|1 |   40 
 |   536 |64
 '- mPrivateFactory, mContext MyActivity @ 0x42d28230|1 
 |  536 |   536 |   127,336
 class com.android.internal.os.ZygoteInit @ 0x41a21a18 System 
 Class   |1 |  120 
 |   536 | 1,000
 '- mResources android.content.res.Resources @ 
 0x41aa7108 |1 
 |  112 |   536 | 8,512
'- mContext android.app.ContextImpl @ 
 0x43009398  |1 
 |  128 |   536 |10,400
   '- mOuterContext MyActivity @ 0x42d4f008  |1 
 |  536 |   536 | 3,864

 ---

 Well that PhoneLayoutInflater shouldn't be holding on to that context of a 
 closed activity, but I don't think I control that. 
 And definitely that ZygoteInit thing shouldn't be holding a context in a 
 static way, but I don't control that either. 

 Any tips on finding the causes better?

 Nathan


 Nathan


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: switch case using string from Enum

[Streets Of Boston]

Yep, you can't do that. 

If 'event' is of type 'Type', then you could do switch(event) { case 
TYPE_ONE:  case TYPE_TWO: ...} ..., because Enum values are considered 
to be constant.

Instead, change your switch statement to if (...) else if (...) { ... } 
else if (...) { ... } else if (...) { ...} .. ... statements. A bit more 
typing, but works well :)

On Friday, July 18, 2014 11:57:03 AM UTC-4, sweety fx wrote:

 *I have the below enum:*

 public enum Type {

 TYPE_ONE(event/one);
 TYPE_TWO(event/two);

 private Type(String mType){
 this.mType = mType;
 }
 private final String mType;

 public String getType(){return mType;}
 }

 *I am trying to compare in Switch/Case:*

  switch (event.getType()){
 case Type.TYPE_ONE.getType():  // says 
 Constant expression required
 Do something:
  case Type.TYPE_TWO.getType(): //  says 
 Constant expression required
 Do something;
 }


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: switch case using string from Enum

[Streets Of Boston]

Not without adding some code yourself.

I have done this many times when values from some JSON string from a server 
map to Enum values but these JSON strings don't map onto the names of the 
Enum values directly.
I usually added a public static method to my Enum class, a factory that 
produces its values based upon a String value:

public enum Type {



public static Type get(String typeStr) {
for (Type value : Type.values()) {
if (value.getType().equals(typeStr)) {
return value;
}
}
return null;
}
}

And now, as an example, in any other part of the code, you can just call 
Type.get(event/one) and get the correct Type value back.

On Friday, July 18, 2014 1:35:27 PM UTC-4, sweety fx wrote:

 Is there a way to pass enum value from the string?
 So that I can make event.getType() to return enum of the string instead of 
 returning string?


 On Friday, July 18, 2014 1:22:45 PM UTC-4, Streets Of Boston wrote:

 Yep, you can't do that. 

 If 'event' is of type 'Type', then you could do switch(event) { case 
 TYPE_ONE:  case TYPE_TWO: ...} ..., because Enum values are considered 
 to be constant.

 Instead, change your switch statement to if (...) else if (...) { ... } 
 else if (...) { ... } else if (...) { ...} .. ... statements. A bit more 
 typing, but works well :)

 On Friday, July 18, 2014 11:57:03 AM UTC-4, sweety fx wrote:

 *I have the below enum:*

 public enum Type {

 TYPE_ONE(event/one);
 TYPE_TWO(event/two);

 private Type(String mType){
 this.mType = mType;
 }
 private final String mType;

 public String getType(){return mType;}
 }

 *I am trying to compare in Switch/Case:*

  switch (event.getType()){
 case Type.TYPE_ONE.getType():  // says 
 Constant expression required
 Do something:
  case Type.TYPE_TWO.getType(): //  says 
 Constant expression required
 Do something;
 }



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: activity.getResoures()

[Streets Of Boston]

If 'res' is a local variable or a member/field of your activity, it's fine 
to use 'res' all over your method/activity.

However, don't make res static/global (if you do and fail to set it to null 
at the appropriate time, you may set yourself up for memory leaks.
Don't give it to other instances of other classes that may store/cache the 
value of 'res' in some place (again, trying to avoid memory leaks).

Calling 'getResources()' is not very expensive. However, to make your code 
more readable, you may want to refactor the call to 'getResources()' into a 
local variable (named 'res' in your case).


On Monday, July 14, 2014 4:26:42 PM UTC-4, sweety fx wrote:

 I have a class which calls activity.getResources() in many places.
 So I defined a private variable 
 *private int Resources res;*

 in onCreate() I defined the value:* res = activity.getResurces()*
  and then used *res* in the all the places.

 is this best practice to do or call activity.getResources() in all the 
 places.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: AndroidStudio - Wipe data between deploys

[Streets Of Boston]

There is, to my knowledge, no such thing as a 'wiping all data of my app' 
programmatically .

However, you can program something similar yourself.

Add a setting (SharedPreferences setting) to your app that stores the 
version-number of your app that the user is running.

Upon start-up, read this setting. Compare this value with the current 
version-number of your app from the package manager. If this current 
version is larger than the one stored in the setting, this means the user 
has just installed a newer version of you app. If the user has installed a 
newer version of your app, then either wipe all the data your app or reset 
it to its default values before you let your user continue.   

On Sunday, June 15, 2014 11:24:36 PM UTC-4, Ricardo Cardoso wrote:

 How do I delete the application between deploys in Android Studio?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Help with native exception: ScriptIntrinsicBlur.create() throws RSRuntimeException: Internal error: Object id 0

[Streets Of Boston]

Be sure to call 'destroy()' on your Renderscript rs variable when you're 
done with it (just before the 'return bm' statement).
It wouldn't hurt to call 'destroy()' on the 'input' and 'ouput' variables 
as well when you're done with it.

Try that and see if this fixes your problem.

On Tuesday, May 20, 2014 3:07:21 PM UTC-4, Sheng-Dean wrote:

 I am implementing Gaussian blurring using the ScriptIntrinsicBlur class. 
 However, I have faced an intermittent issue where sometimes 
 ScriptIntrinsicBlur.create() throws  RSRuntimeException: Internal error: 
 Object id 0. 

 Here is the most stacktrace that I can post:

  android.renderscript.RSRuntimeException: Internal error: Object id 0.

   
   at android.renderscript.BaseObj.getID(BaseObj.java:57)

   
   at android.renderscript.Script.setVar(Script.java:202)

   
   at 
 android.renderscript.ScriptIntrinsicBlur.setRadius(ScriptIntrinsicBlur.java:80)

   
   at 
 android.renderscript.ScriptIntrinsicBlur.create(ScriptIntrinsicBlur.java:54)


 The bitmap that is being blurred is usually around 300*300 ~ 400*400 
 pixels and the blurRadius is set to 20. 

 private static Bitmap blurBitmap(Context context, Bitmap bm, float 
 blurRadius) {
 if (context == null || bm == null || blurRadius  0) {
 return null;
 }

 try {
 /* Make image width a multiple of 4. This is to avoid a bug in 
 the
  * implementation of ScriptIntrinsicBlur that causes visual
  * artifacts Source:
  * https://plus.google.com/+RomanNurik/posts/TLkVQC3M6jW */
 if (bm.getWidth() % 4 != 0) {
 bm = Bitmap.createBitmap(bm, 0, 0, bm.getWidth() - 
 (bm.getWidth() % 4), bm.getHeight());
 }

 final RenderScript rs = RenderScript.create(context);
 final Allocation input = Allocation.createFromBitmap(rs, bm, 
 Allocation.MipmapControl.MIPMAP_NONE,
  
 Allocation.USAGE_SCRIPT);
 final Allocation output = Allocation.createTyped(rs, 
 input.getType());
 final ScriptIntrinsicBlur script = 
 ScriptIntrinsicBlur.create(rs, Element.U8_4(rs));

 script.setRadius(blurRadius);
 script.setInput(input);
 script.forEach(output);
 output.copyTo(bm);

 } catch (RSRuntimeException e) {
 /* Throws android.renderscript.RSRuntimeException: Internal 
 error:
  * Object id 0. */
 }
 return bm;
 }

 The exception is being thrown when create() is being called. I traced the 
 ScriptIntrinsicBlur.create() method and it am guessing that my problem 
 starts here:

 int id = rs.nScriptIntrinsicCreate(5, e.getID(rs));
 ScriptIntrinsicBlur sib = new ScriptIntrinsicBlur(id, rs);
 sib.setRadius(5.f);

 I am guessing that the native method nScriptIntrinsicCreate() may be 
 returning 0, which is passed to the constructor, then when setRadius() is 
 called it does a check and throws the exception. My questions are:
 1. What does nScriptIntrinsicCreate() do and what can cause 
 nScriptIntrinsicCreate() to return 0?
 2. How do you go about debugging native methods? 


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: ListView getCount is wrong - how do I reset it?

[Streets Of Boston]

It's bad programming practice, but you inherited it, so you need to deal 
with it.. :-)

Question, though, and if this applies to your problem, you'll see why it is 
bad practices to make it static.

Your ListActivity, does it have more than one instance? In other words, are 
there more than one ListActivities that access/use this static arraylist of 
Strings?
If so, you, that could be your problem. 

It does matter that the arraylist of strings (listItems) is static. You may 
have more than one ListActivity instances around at any given time, sharing 
the same arraylist (through their ListView's adapters) and this opens a big 
can of worms.
If this is the cause of the issue, then you really should change the 
architecture. If you don't have the authority, tell whomever (didn't) give 
you that authority what the problem is and how you would like to properly 
solve it. 

On Monday, May 19, 2014 9:42:47 AM UTC-4, plnelson wrote:



 It's public and static because the method in the ListActivity that calls 
 it is static.   So if it wasn't static it would generate a compile-time 
 error that a static method can't refence a non-static object.   The 
 ListActivity method is static is that way because that's how the original 
 program was architected and I don't have the authority to change the 
 architecture.

 But why does it matter?Why can't the size of a ListView be reset if 
 it's static?


 On Saturday, May 17, 2014 4:11:48 AM UTC-4, Doug wrote:



 On Friday, May 16, 2014 11:58:17 AM UTC-7, plnelson wrote:

 ...In MyListActivity, which is a ListActivity . . .

 public static ListView lv;   // my ListView in the code


 Why is this public and static?
  

 ...the data source is an ArrayList called listItems. The first time 
 around it has 12 items in it; later I clear it and add in 6 items. (see 
 below)

 public static ArrayListStringlistItems=new ArrayListString();


 Why is this public and static?
  

 ... in my adapter, which is a BaseAdapter, my override of getCount() 
 looks like this. After shrinking listItems to 6 it correctly returns 6.

 @Override
 public int getCount() {
 return listItems.size();
 }

 ... To shrink my dataset to 6 I first do a

 listItems.clear();
 lv.invalidate();   // my (failed) attempt to get lv to reset its count


 Invalidate doesn't do what you think it does.  That has to do with the 
 rendering of the view on screen, not the contents of the adapter that the 
 ListView knows about.
  

 ... and then add in the 6 new items. After adding each item to listItems 
 I do a notifyDataSetChanged() on the adapter. What I've noticed is that if* 
 I do an lv.getCount it returns 12, i.e., the value it was before doing the 
 listItems.clear()* and invalidate(). Why does the ListView still think 
 it's 12? How do I reset it? Is that why the adapter thinks it's too big?


 Try setting a new (non-public, non-static) adapter into the ListView 
 instead.

 Never change the contents of the data in an adapter after you've given it 
 to the ListView.  Make a deep copy of the data before sending it if you 
 have to.

 Doug



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: ListView getCount is wrong - how do I reset it?

[Streets Of Boston]

Debug the listItems (ArrayList of Strings). Monitor its add method(s), i.e. 
set breakpoints on them, and figure out which code adds to this static list 
without notifying the ListAdapter(s). 


On Monday, May 19, 2014 9:53:44 AM UTC-4, plnelson wrote:


 I call if after adding each one mostly for diagnostics -  I wanted to see 
 in the debugger what changed and when.   That's the same reason I'm getting 
 the list items size -  for diagnostics, for debugging this problem.

 *It's all for the same question *- How do I get ListView to report its 
 correct size in getCount after the the size of its dataset changes?   When 
 the size of listItems was 12 the listView's getCount returned 12; After 
 I've changed the size of listItems to 6 I expect the ListView's getCount to 
 return 6 - how to I get ListView to correctly return its new count?




 On Monday, May 19, 2014 3:39:33 AM UTC-4, Rufatet Babakishiyev wrote:

 After adding each item to listItems I do a notifyDataSetChanged() on the 
 adapter.

 Why you call adter adding each time.

 public void updateListItems(){
// TODO clear list
// TODO Add element to list
// TODO NOTIFY DATA SET CHANGED
// TODO try to get list item size (I do not know why you need it)
 }

 P.S Sure you created adapter with this list and adapter set to list.


 On Friday, May 16, 2014 11:58:17 PM UTC+5, plnelson wrote:

 I have a listView in an android app which works fine when I first 
 populate it - it displays and scrolls with no problem. But if I load in a 
 new, smaller dataset and call notifyDataSetChanged() the app crashes 
 because getView() gets called with a position value that's bigger than the 
 dataset, i.e., if listItems.size==6, valid values for position should be 
 [0]-[5] but getView() is called with 6, so I'm getting index out of bounds 
 when I try to access an item in my list. While investigating this I noticed 
 that* ListView's getCount() is still returning the old value of 12.*

 Details:

 ...In MyListActivity, which is a ListActivity . . .

 public static ListView lv;   // my ListView in the code

 ... during onCreate() . . .

setContentView(R.layout.mylist);
lv = getListView();

 create the adapter and bind it . . .

 mylistadapter = new MyListAdapter(MyListActivity.this);
 setListAdapter(mylistadapter);   // bind the adapter

 ...the data source is an ArrayList called listItems. The first time 
 around it has 12 items in it; later I clear it and add in 6 items. (see 
 below)

 public static ArrayListStringlistItems=new ArrayListString();

 ... in my adapter, which is a BaseAdapter, my override of getCount() 
 looks like this. After shrinking listItems to 6 it correctly returns 6.

 @Override
 public int getCount() {
 return listItems.size();
 }

 ... To shrink my dataset to 6 I first do a

 listItems.clear();
 lv.invalidate();   // my (failed) attempt to get lv to reset its count

 ... and then add in the 6 new items. After adding each item to listItems 
 I do a notifyDataSetChanged() on the adapter. What I've noticed is that if* 
 I do an lv.getCount it returns 12, i.e., the value it was before doing the 
 listItems.clear()* and invalidate(). Why does the ListView still think 
 it's 12? How do I reset it? Is that why the adapter thinks it's too big?




-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: position value in getView seems too big

[Streets Of Boston]

The ListAdapter's max value of the 'position' parameter of its getView(...) 
method is determined by the ListAdatper's getCount() method. It will never 
be larger than the value returned by getCount(): 

0 = position  getCount()

I have never seen position being larger or equal than getCount()'s return 
value, unless the ListAdapter is in an inconsistent state.

The ListAdapter can be in an inconsistent state when its underlying data is 
changed without notifying the ListAdapter (notifyDataSetChanged()). E.g


static ListString someListItems = ... ...

...
ListAdapter adapter = new MyListAdapter();
listView.setAdapter(adapter);
...
... 

public MyListAdapter extends . {
...

public int getCount() {
return someListItems.size();
}

...
}
...

Say some piece of code has access to the reference named 'someListItems', 
either code in the same class or somewhere else in another class: 

someListItems.add(newItem);
someListItems.remove(removeIndex);
// If we don't call the ListAdapter's notifyDataSetChanged() now, we 
can get very strange results. 
// The ListAdapter is in an inconsistent state, because its getCount() 
will return a different unexpected value and this
// value could now be less than the known available 'position' values 
(as known by the ListView) to be used for calls to getView(...).


On Monday, May 19, 2014 12:14:43 PM UTC-4, plnelson wrote:


 I am calling notifyDataSetChanged().  

 If I override it in my adapter, to add a log trace, this does get hit and 
 the trace happens . . . 







 *// just overriding notifyDataSetChanged() to instrument it
 @Overridepublic void notifyDataSetChanged() {
 Log.e (notifyDataSetChanged()...,   listItems.size()= + 
 String.valueOf(listItems.size()) +   lv.getCount()= + 
 String.valueOf(lv.getCount()) );   //!! debugging
 super.notifyDataSetChanged();} *   


 The dataset -  listItems - returns a size of 6.   But *getView(*) gets 
 called with position values up to 12 (there are 12 items visible on the 
 screen because that's how many items there *used to be* in the dataset,)

 So why is getView being called with a position value greater that the 
 (current) largest index in its dataset?
 Another way to think of this question is how does getView know the largest 
 value of position it can have?

 (BTW I solved the ListView.getCount() problem by calling setListAdapter() 
 on the ListActivity after updating the datasource.   As a result ListView's 
 *getCount()* now accurately reflect the the number of list items.   That 
 seems to have no affect on this bug.




 On Thursday, May 15, 2014 2:09:57 PM UTC-4, plnelson wrote:


 I'm getting a crash in my adapter's *getView()* routine because it's 
 being called with a position value of 6 and my datasource only has 6 items 
 in it. So I assumed that the position parameter should be in a range of 
 [0]-[5]? What determines the range of values in *getView(*)'s position 
 parameter?

 Details:

 the XML ...

 ListView
   android:id=@android:id/list
   android:layout_height=match_parent
   android:layout_width=match_parent
   android:cacheColorHint=@color/colGrey
   android:background=@color/colGrey
   android:clickable=true
   android:fastScrollEnabled=true
   android:choiceMode=none/


 ...In MyListActivity, which is a ListActivity . . .

 public static ListView lv;   // my ListView in the code


 ... during *onCreate()* . . .

setContentView(R.layout.mylist);
lv = getListView();


 create the adapter and bind it . . .

 mylistadapter = new MyListAdapter(MyListActivity.this);
 setListAdapter(mylistadapter);   // bind the adapter


 ...the data source is an ArrayList called listItems. during the course of 
 running the program its size varies and it may have been 15 earlier in 
 program execution . . .

 public static ArrayListStringlistItems=new ArrayListString();


 ... in my adapter, which is a BaseAdapter, my ovveride of getCount() 
 looks like this . . .

 @Override
 public int getCount() {
 return listItems.size();
 }


 ... when I call *getCount()* in *getView()* it returns 6, which is the 
 number of items in the data source, but if I call lv.*getView(*) it 
 returns 15. (any idea where this 15 is coming from?) Could that be why the 
 adapter is calling *getView()* with index too big?

 Thanks in advance!




-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop 

[android-developers] Re: position value in getView seems too big

[Streets Of Boston]

That is hard to figure out without you posting the code of your adapter and 
how you create an instance of your adapter. It is probably a subtle bug...

On Friday, May 16, 2014 2:34:19 PM UTC-4, plnelson wrote:


 Sorry -  should be lv.get*Count*.

 And yes, I am calling notifyDataSetChanged.   

 I've also tried calling the ListView's *invalidate()* method, with no 
 change in the behavior.

 Since posting this I've written a whole separate version of the program 
 where I initially display 12 items ( listItems.size() == 12).  That part 
 works fine.  I then shrink my list to 6 by ...


- clear my listItems 

 *  (  listItems.size() == 0  )*

- add in 6 new items 

 *  (  listItems.size() == 6  )*

- call notifydataSetChanged()


 ... but the ListView's getCount still returns 12!Why?And is this 
 why the adapter's getCount() returns with an index that's too high for it's 
 dataset?





-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: position value in getView seems too big

[Streets Of Boston]

There is no method 'getView' on a ListView class. And i expect i wouldn't 
return a number

However, you do define a *static *field called *listItems*. Do you update 
the *listItems *field directly without notifying the your *BaseAdapter*? If 
so, this could be the problem. Notify the *BaseAdapter *by calling 
'notifyDataSetChanged()' on it after you make the appropriate changes to 
its data (*listItems*).

Note that you should not make this field (*listItems*) a *static*/class 
field. Just make it a regular/instance field, fill it with data and send 
this to your BaseAdapter and let your BaseAdapter handle it.

On Thursday, May 15, 2014 2:09:57 PM UTC-4, plnelson wrote:


 I'm getting a crash in my adapter's *getView()* routine because it's 
 being called with a position value of 6 and my datasource only has 6 items 
 in it. So I assumed that the position parameter should be in a range of 
 [0]-[5]? What determines the range of values in *getView(*)'s position 
 parameter?

 Details:

 the XML ...

 ListView
   android:id=@android:id/list
   android:layout_height=match_parent
   android:layout_width=match_parent
   android:cacheColorHint=@color/colGrey
   android:background=@color/colGrey
   android:clickable=true
   android:fastScrollEnabled=true
   android:choiceMode=none/


 ...In MyListActivity, which is a ListActivity . . .

 public static ListView lv;   // my ListView in the code


 ... during *onCreate()* . . .

setContentView(R.layout.mylist);
lv = getListView();


 create the adapter and bind it . . .

 mylistadapter = new MyListAdapter(MyListActivity.this);
 setListAdapter(mylistadapter);   // bind the adapter


 ...the data source is an ArrayList called listItems. during the course of 
 running the program its size varies and it may have been 15 earlier in 
 program execution . . .

 public static ArrayListStringlistItems=new ArrayListString();


 ... in my adapter, which is a BaseAdapter, my ovveride of getCount() looks 
 like this . . .

 @Override
 public int getCount() {
 return listItems.size();
 }


 ... when I call *getCount()* in *getView()* it returns 6, which is the 
 number of items in the data source, but if I call lv.*getView(*) it 
 returns 15. (any idea where this 15 is coming from?) Could that be why the 
 adapter is calling *getView()* with index too big?

 Thanks in advance!




-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: image not coming proper some times lazy loading grid view

[Streets Of Boston]

Not sure if this would work, but may be worth a try:

Before you close the FileOutputStream 'fs', have you tried to call 
fs.getFD(),sync() ?

On Wednesday, December 4, 2013 3:00:43 AM UTC-5, Amit Mangal wrote:

 Hi there,
 i am loading images on grid view using lazy loading from network. problem 
 is not some times image is not coming properly i have attached the screen 
 shot.

 here is my lazy loading code 

 private Bitmap getBitmap(String url) 
 {
 File f=fileCache.getFile(url);
 
 Bitmap b = showImage(f);
 if(b!=null)
 return b;
 
 //from web
 try {
 Bitmap bitmap=null;
 URL imageUrl = new URL(url);
 HttpURLConnection conn = 
 (HttpURLConnection)imageUrl.openConnection();
 conn.setConnectTimeout(6);
 conn.setReadTimeout(6);
 conn.setInstanceFollowRedirects(true);
 InputStream is=conn.getInputStream();
 OutputStream os = new FileOutputStream(f);
 Utils.CopyStream(is, os);
 os.close();
 //bitmap = decodeFile(f);
 bitmap =  showImage(f); 
 return bitmap;
 } catch (Throwable ex){
ex.printStackTrace();
if(ex instanceof OutOfMemoryError)
memoryCache.clear();
return null;
 }
 }
 
 private Bitmap showImage(File file)   {
 //Log.i(showImage,loading:+path);
 BitmapFactory.Options bfOptions=new BitmapFactory.Options();
 bfOptions.inDither=false; //Disable Dithering 
 mode
 bfOptions.inPurgeable=true;   //Tell to gc that 
 whether it needs free memory, the Bitmap can be cleared
 bfOptions.inInputShareable=true;  //Which kind of 
 reference will be used to recover the Bitmap data after being clear, when 
 it will be used in the future
 bfOptions.inTempStorage=new byte[32 * 1024]; 


 //File file=new File(path);
 FileInputStream fs=null;
 try {
 fs = new FileInputStream(file);
 } catch (FileNotFoundException e) {
 //TODO do something intelligent
 e.printStackTrace();
 }

 Bitmap bm = null ;
 try {
 if(fs!=null) bm 
 =BitmapFactory.decodeFileDescriptor(fs.getFD(), null, bfOptions);
 } catch (IOException e) {
 //TODO do something intelligent
 e.printStackTrace();
 } finally{ 
 if(fs!=null) {
 try {
 fs.close();
 } catch (IOException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
 }
 }
 }
 //bm=BitmapFactory.decodeFile(path, bfOptions); This one causes 
 error: java.lang.OutOfMemoryError: bitmap size exceeds VM budget

   //  im.setImageBitmap(bm);
 //bm.recycle();
  //   bm=null;
  return bm ;


 }


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: With Updated APK, Can't Purge Previous Data

[Streets Of Boston]

If your updated APK has its own SQLite database and your app uses a 
sub-class of SQLiteOpenHelper, you could increase your database version 
each time your update your app (increase version value in SQLiteOpenHelper 
constructor) and implement that sub-class' onUpgrade method to clear out 
data (e.g. delete files or caches, etc). 

http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html

Note that your implementing the onUpgrade is mainly meant to upgrade the 
SQLite database(s) of your app, but you could do other stuff as well, such 
as deleting files, clearing SharedPreferences, etc.
 

On Monday, December 2, 2013 7:03:58 AM UTC-5, Cayce wrote:

 This is making me crazy. I'm having an app built that is initially 
 downloaded as an empty carrier for different regions of data. The person 
 using the app will then choose the region/data to be purchased, make that 
 in-app purchase, and the region/data loads into the app shell. I have to 
 test each updated APK by going through the process of purchasing a region 
 of data. The problem is that even after deleting the previous install of 
 the previous APK, the newly updated APK shows the previous APK's purchases.

 The only way I've been able to work around this is to create a whole new 
 GMail account with each updated APK, delete the previous accounts on my 
 testing devices, and start over. Aside from the time consuming process this 
 entails, Google requires telephone (voice or text) verification of each 
 newly created GMail account, and only allows one phone number to be used a 
 certain number of times before it won't allow that number any longer. It's 
 about 5 times, I think. I've run out of phone numbers.

 The question: How are other developers dealing with this? How can I purge 
 the data from a previously installed APK? The data isn't in the device, 
 because I did a factory reset this morning thinking I would just do that 
 each time, reloaded a new APK, and the previous in-app purchases showed up.

 Any help would be appreciated.

 Thanks.

 Cayce


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: ViewPager does not respect WRAP_CONTENT?

[Streets Of Boston]

The ViewPager specified WRAP_CONTENT as its width.
What content?

The ViewPager can show more than one page and only one is visible at a 
time. If it had to choose the 'content' to use to figure out how wide the 
WRAP_CONTENT width should be, which page should it use?
WRAP_CONTENT doesn't make sense for a ViewPager.

ViewPager should have a fixed width, either through MATCH_PARENT or through 
a set number of pixels (dpi). If the ViewPager shouldn't occupy the entire 
width of the screen, you could (for example) use a horizontal LinearLayout 
with three child views: Two plain Views; one on the left, one on the right; 
One ViewPager in the middle. Set the layout_widths to all of them to 0dp 
and assign an appropriate layout_weight to all three of them. 


On Friday, November 22, 2013 3:11:43 PM UTC-5, Ab wrote:

 I would like to create a ViewPager whose width wrap's to its contents, and 
 is centered horizontally in it's parent.  The first code snippet uses a 
 LinearLayout to create this effect, as shown in the first screenshot.  The 
 second code snippet is my attempt to do this with a ViewPager instead of 
 the LinearLayout, but the result is not the desired behavior, as shown in 
 the second screenshot.

 Any suggestions as to how I create the first effect, but using a ViewPager?

   @Override
 protected void onCreate(Bundle savedInstanceState) 
 {
 super.onCreate(savedInstanceState);
 
 textView = new TextView(this);
 textView.setLayoutParams(new 
 ViewGroup.LayoutParams(LinearLayout.LayoutParams.WRAP_CONTENT, 
 LinearLayout.LayoutParams.WRAP_CONTENT));
 textView.setText(abcabcabcabcabc);
 textView.setBackgroundColor(Color.YELLOW);
 
 LinearLayout llayout = new LinearLayout(this);
 llayout.setBackgroundColor(Color.BLUE);
 RelativeLayout.LayoutParams layoutParams = new 
 RelativeLayout.LayoutParams(RelativeLayout.LayoutParams.WRAP_CONTENT, 
 RelativeLayout.LayoutParams.MATCH_PARENT);
 layoutParams.addRule(RelativeLayout.CENTER_HORIZONTAL);
 llayout.setLayoutParams(layoutParams);
 llayout.addView(textView);
 
 layout = new RelativeLayout(this);
 layout.setLayoutParams(new 
 ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, 
 ViewGroup.LayoutParams.MATCH_PARENT));
 layout.setBackgroundColor(Color.GREEN);
 layout.addView(llayout);
 
 setContentView(layout);
 }
 
 
 @Override
 protected void onCreate(Bundle savedInstanceState) 
 {
 super.onCreate(savedInstanceState);
 
 textView = new TextView(this);
 textView.setLayoutParams(new 
 ViewGroup.LayoutParams(ViewPager.LayoutParams.WRAP_CONTENT, 
 ViewPager.LayoutParams.WRAP_CONTENT));
 textView.setText(abcabcabcabcabc);
 textView.setBackgroundColor(Color.YELLOW);
 
 ViewPager pager = new ViewPager(this);
 pager.setBackgroundColor(Color.BLUE);
 RelativeLayout.LayoutParams layoutParams = new 
 RelativeLayout.LayoutParams(RelativeLayout.LayoutParams.WRAP_CONTENT, 
 RelativeLayout.LayoutParams.FILL_PARENT);
 layoutParams.addRule(RelativeLayout.CENTER_HORIZONTAL);
 pager.setLayoutParams(layoutParams);
 pager.setAdapter(new ViewPagerAdapter());
 
 layout = new RelativeLayout(this);
 layout.setLayoutParams(new 
 ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, 
 ViewGroup.LayoutParams.MATCH_PARENT));
 layout.setBackgroundColor(Color.GREEN);
 layout.addView(pager);
 
 setContentView(layout);
 }
 
 class ViewPagerAdapter extends PagerAdapter
 {
 @Override
 public int getCount() 
 {
 return 1;
 }
 
 public Object instantiateItem(ViewGroup collection, int 
 position) 
 {
 collection.addView(textView, 0);
 return textView;
 }
 
 @Override
 public void destroyItem(ViewGroup collection, int position, 
 Object view) 
 {
 collection.removeView((View) view);
 }
 
 @Override
 public boolean isViewFromObject(View view, Object object) 
 {
 return (view==object);
 }
 
 @Override
 public void finishUpdate(ViewGroup arg0) {}
 
 
 @Override
 public void restoreState(Parcelable arg0, ClassLoader arg1) {}
 
 @Override
 public Parcelable saveState() 
 {
 return null;
 }
 
 @Override
 public void startUpdate(ViewGroup arg0) {}
 }

 ![enter image description here][1]

 ![enter image description here][2]


   [1]: http://i.stack.imgur.com/6Ajm7.png
   [2]: http://i.stack.imgur.com/qWYQY.png


-- 
You received this message because you are subscribed to the Google

[android-developers] Re: does executable code change (improve) with increase in minSdkVersion declaration in manifest? is minsdk 11 declaration really needed for tablets?

[Streets Of Boston]

*minSdkVersion:*
If this is less than the version you are compiling against, *you *have to 
take care with Java code (methods/classes/etc) that is defined in 
sdk-versions higher than the declared minSdkVersion. *You *have to deal 
with making your code somehow compatible with older sdk-versions.

When you increase your app's minSdkVersion, your code may become a bit less 
complicated, since you no longer have to deal with compatibility of the 
sdk-version lower than your declared minSdkVersion. But your app becomes 
unavailable to users with older devices (if they download it from Google 
Play).

When you decrease your app's minSdkVersion (which would hardly ever 
happen), your code may become more complicated, since you have to deal with 
compatibility with even older versions of the android sdk. Your app will 
become available to users with older devices (if they download it from 
Google Play).

*targetSdkVersion:*
This equal or more than your minSdkVersion.

When you change this, (default) behavior of certain classes/components/etc 
may change on devices that run Android versions equal or larger(/newer) 
than your declared targetSdkVersion. When you change this, you'll need to *test 
your app thoroughly *again! *Google *implements a so-called compatibility 
layer that cues of the declared targetSdkVersion and the 
compatibility-layer's behavior differs for different values of 
targetSdkVersion. 


Changing the minSdkVersion won't do anything for 'improving the run time', 
if you mean 'improve performance' by that.
Changing the targetSdkVersion won't do anything for performance either, but 
it may increase usability, look-and-feel, behavior on certain types of 
devices that run your app. You need to test this, though. 


On Monday, October 28, 2013 10:26:06 AM UTC-4, firebreather wrote:

 info seems fuzzy on the impact of changing minsdkversion declaration, 
 particularly in the android docs, where it appears to just limit the number 
 of phones the app site will allow to download your app. if that was the 
 case then you'd think everyone would just declare minsdk of 1.
  
 i'm developing on version 14 with minsdk declared of 10 (recently up from 
 8). my biggest user categories are tablets according to my dashboard. 
 according to the docs, I need minsdk declaration of 11, among several other 
 things, for tablets to use my apps. 
  
 is this bad information? why can tablets use my app now if 11 is really 
 needed?
  
 will raising the min to 11 change the executable code, improving the run 
 time for my games on version 11 and up phones and tablets?
  
 thank you.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Is this OK ? (Triggering an event in an Activity from a Service)

[Streets Of Boston]

Yep, this is fine for a *local* Service.

For a Service that could be remote, you'd need some other way of 
communicating (Service sending BroadCasts to a BroadCastReceiver in/of the 
Activity; ResultReceiver provided by the Acivity to the Service; AIDL; etc).

On Wednesday, September 4, 2013 10:56:15 AM UTC-4, RLScott wrote:


 I suppose from the absence of critiques of this method that no one sees 
 anything wrong with it.  If that is the case then why have I not seen any 
 examples using this very simple method of a service triggering an event in 
 an activity that has bound to the service?

 Robert Scott
 Hopkins, MN



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: What is the use of services in Android?

[Streets Of Boston]

For option 2, use an IntentSerrvice. Then you don't have to worry about 
calling 'stopService'. It does it for you when necessary.


On Thursday, August 8, 2013 7:40:02 AM UTC-4, ashish wrote:

 I read about services in Android very carefully, but I didn't find any 
 valid reasons to use it. E.g.

1. 

By default services run in the main thread, which most of the 
applications don't want.
2. 

A service can run on a seperate thread if it spawns it own thread. But 
if a service runs on a seprate thread, then the method stopService(new 
Intent(getApplicationContext(), MyService.class)); does not stop the 
running service. Again this is a problem.

 If we want to do some background operations, then I think threads are 
 better than services. Am I right?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] What is the use of services in Android?

[Streets Of Boston]

Send another Intent (different action) to the IntentService. Override the 
onStartCommand to catch this Intent and this could allow you to 
stop/interrupt the ongoing process in the IntentService's background thread.

On Thursday, August 8, 2013 2:04:33 PM UTC-4, ashish wrote:

 Hi,

 if a service starts a  new thread then how i can stop the service from the 
 other class.

 On Thursday, August 8, 2013 3:51:19 AM UTC-8, Kristopher Micinski wrote:

 Usually you use a service to coordinate a thread.

 FYI most of the time you don't want to outright kill a thread (e.g., if 
 it's about to return from a download operation), you want to periodically 
 check a flag.

 You probably don't want to use threads in their raw fashion (from 
 activities) for a few reasons, one of which being that with configuration 
 changes they're trickier to get right.  Instead if you need background work 
 that fits the model, an AsyncTask is an appropriate design.

 Kris


 On Thu, Aug 8, 2013 at 7:40 AM, ashish ashis...@gmail.com wrote:

 I read about services in Android very carefully, but I didn't find any 
 valid reasons to use it. E.g.

1. 

By default services run in the main thread, which most of the 
applications don't want.
2. 

A service can run on a seperate thread if it spawns it own thread. 
But if a service runs on a seprate thread, then the method 
 stopService(new 
Intent(getApplicationContext(), MyService.class)); does not stop the 
running service. Again this is a problem.

 If we want to do some background operations, then I think threads are 
 better than services. Am I right?
  
 -- 
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-d...@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups Android Developers group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to android-developers+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: GLSurfaceView lag/delay on Galaxy S3.

[Streets Of Boston]

Running out of ideas here :-)

The test wasn't meant to see if Canvas would work or not. It was about the 
speed of the touch-event-message delivery. 
At least we figured out it isn't an issue with the onTouch callbacks. They 
happen fast enough.

What happens if you play with the values of the call to 
surfaceView.setEGLConfigChooser(8,8,8,8,8,8);

Try 8, 8, 8, 8, 0, 0 (no depth, no stencil).
Even try 5, 6, 5, 0, 0, 0 (RGB565, no depth, no stencil).

The GLSurfaceView uses the swapBuffers command I have seen this being quite 
slow on some devices (admittedly, they all ran Cyanogen, no stock OSes). 
And on top of that, it is a locking call.


On Thursday, August 1, 2013 5:30:57 AM UTC-4, Edvinas Kilbauskas wrote:

 OK, I did that. And yes. It doesn't have the delay anymore! But the 
 problem is... It's Canvas. I don't need canvas, it doesn't fulfill my 
 needs. I need OpenGL.
 What the hell could be wrong? This is REALLY strange. OpenGL ES 1.0 has 
 delay, ES 1.1 has delay, ES 2.0 has delay. Canvas - no delay!
 This should be other way around, because as far as I know canvas uses 
 software rendering, while OpenGL uses hardware, which should be way faster!
 Any more ideas?


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: GLSurfaceView lag/delay on Galaxy S3.

[Streets Of Boston]

Is your render-mode continuously or when-dirty? 
If it is when-dirty, be sure to call surfaceView.requestRender() in your 
onTouchEvent implementation.

On Tuesday, July 30, 2013 7:14:22 AM UTC-4, Edvinas Kilbauskas wrote:


 The best solution to your problem is probably to bite the bullet and 
 rewrite your code to use shaders in OpenGL ES 2.0. All major phones and 
 quite a few minor ones support it now.

 It may be your only solution, if the Galaxy S3 has to move too many more 
 bits than the P350 did, or has a slower OpenGL client-server path. Or if 
 Motorola took too many shortcuts in maintaining OpenGL ES 1.0 backwards 
 compatibility.

 Finally, from this snippet, we cannot tell if you are handling your 
 buffers correctly. For example is 'buffer' a directly allocated ByteBuffer?



 This is full code, I optimized it even more, but only making 4 OpenGL 
 calls every frame.


 public class MainActivity extends Activity implements Renderer, 
 OnTouchListener {

 private GLSurfaceView surfaceView;

 private FloatBuffer vertices;

 private float x;

 private float y;

 private int SCREEN_WIDTH = 1280;

 private int SCREEN_HEIGHT = 720;


 @Override

 protected void onCreate(Bundle savedInstanceState) {

 super.onCreate(savedInstanceState);


 surfaceView = new GLSurfaceView(this);

 surfaceView.setOnTouchListener(this);

 surfaceView.setEGLConfigChooser(8,8,8,8,8,8);

 surfaceView.setRenderer(this);


 vertices = ByteBuffer.allocateDirect(12 * 
 4).order(ByteOrder.nativeOrder()).asFloatBuffer();


 vertices.put(new float[]{

 -1,-1,

  1,-1,

 -1, 1,

 -1, 1,

  1, 1,

  1,-1

 });

 vertices.flip();


 setContentView(surfaceView);

 }


 public boolean onTouch(View view, MotionEvent motionEvent){

 x = motionEvent.getRawX();

 y = motionEvent.getRawY();


 return true;

 }


 public void onDrawFrame(GL10 gl){

 gl.glClear(GL10.GL_COLOR_BUFFER_BIT);

 float frustumWidth = SCREEN_WIDTH/100.0f;

 float frustumHeight = SCREEN_HEIGHT/100.0f;


 gl.glLoadIdentity();

 
 gl.glTranslatef((x/SCREEN_WIDTH)*frustumWidth,(y/SCREEN_HEIGHT)*frustumHeight,0);

 gl.glDrawArrays(GL10.GL_TRIANGLES, 0, 6);


 }


 public void onSurfaceChanged(GL10 gl, int width, int height){

 gl.glViewport(0,0,SCREEN_WIDTH,SCREEN_HEIGHT);

 gl.glMatrixMode(GL10.GL_PROJECTION);

 gl.glLoadIdentity();


 gl.glOrthof(0,SCREEN_WIDTH/100.0f,SCREEN_HEIGHT/100.0f,0,-1,1);


 gl.glMatrixMode(GL10.GL_MODELVIEW);


 gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);

 gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices);

 }


 public void onSurfaceCreated(GL10 gl, EGLConfig config){


 }


 }


 You can't make it any simpler than that, and there is still delay.

 Well, I guess I will have to move on to OpenGL ES 2.0, I was actually 
 planning on rewriting that framework in ES 2.0 entirely, but only after I 
 finish this game first. So I guess I have to stop working on my game, and 
 start rewriting my framework now... I HOPE this will do the trick. If not, 
 then i'm screwed, big time.
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: GLSurfaceView lag/delay on Galaxy S3.

[Streets Of Boston]

I looked at your video. 
It seems that the drawing itself is not an issue. The framerate doesn't 
stutter nor is it slow. It just lags behind the position of your finger.

It seems that the delivery of the touch-events is delayed (at least as far 
as the rendering is concerned).

Try to create a non-OpenGL view. Just subclass a regular View, override its 
onDraw method and its onTouch method. 
Based on the X and Y coords of the onTouch method, draw a circle under your 
finger in the onDraw method of that view. See if it exhibits the same lag.



On Wednesday, July 31, 2013 1:06:22 PM UTC-4, Edvinas Kilbauskas wrote:



 2013 m. liepa 31 d., trečiadienis 19:28:23 UTC+3, Streets Of Boston rašė:

 Is your render-mode continuously or when-dirty? 
 If it is when-dirty, be sure to call surfaceView.requestRender() in your 
 onTouchEvent implementation.


 It's RENDERMODE_CONTINUOUSLY.

 Also, I took the advice, and rewrote everything in OpenGL ES 2.0. And you 
 know what? It still has the same amount of delay! What the hell?
 I really though ES 2.0 would fix this issue, but it didn't!
 Now i'm really thinking that this issue is not fixable. It probably has 
 something to do with drivers.
 But I still can't get out of my head why some other games have no lag or 
 delay? Some games do, but not all of them. Or atleast I think they don't 
 have delay, maybe it just seem like that... I don't know it's very 
 annoying, If I turn power saving mode off it becomes better, but still has 
 delay. 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Handling process killed by system

[Streets Of Boston]

The singletons stick around as long as your process is alive.

If your process is killed (and therefore your DalvikVM running your app), 
nothing sticks around, including your static variables/fields. This is just 
like any other Java/C/C++ app. The issue is that the OS kills your process, 
not the user and therefore can be highly unpredictable.

That's why your Activities and Fragments have a onSaveInstanceState method.Use 
this to save your session variables into the provided Bundle and pick them 
up again from the 'Bundle savedInstanceState' in your Actiivty's/Fragment's 
onCreate 
method.

If your session variable are complex, let your session objects implement 
Parcelable, which can be saved properly into Bundles. 
You could also have them implement Serializable instead, which can be saved 
to Bundles as well. This'll save you some coding, but is quite bad 
performance-wise. 


On Friday, June 21, 2013 10:25:33 AM UTC-4, Benoit Vermont wrote:

 Hi, I've been reading intensively the Android Application Framework FAQ (
 http://developer.android.com/guide/faq/framework.html) and it says that 
 the system can kill process if needed to free memory.

 Well, fair enough, only it also destroys singletons and static instances. 
 So when we launch the application back after that, it tries to restore 
 itself, but fails miserably because all static singletons are no more 
 available.

 What bugs me is that the same documentation (Framework 
 FAQ) specifically says : You can take advantage of the fact that your 
 application components run in the same process through the use of a 
 singleton. This is a class that is designed to have only one instance. It 
 has a static method with a name such as getInstance() that returns the 
 instance; the first time this method is called, it creates the global 
 instance. Because all callers get the same instance, they can use this as a 
 point of interaction. For example activity A may retrieve the instance and 
 call setValue(3); later activity B may retrieve the instance and call 
 getValue() to retrieve the last set value.

 But it's not so true, as these singletons are not reliable at all.

 I mainly use singleton in my apps to store session variable. But some of 
 this variables are quite complex (it can be information about the user, 
 trees of object, etc). For exemple, I'm working on an ordering application 
 that stores in a singleton a map of stuff the user wan't to buy. This maps 
 is complex, it could also store information such as what kind of shipping 
 option does the user want, etc...

 But let's say I start the app on a cheap device (with low memory), I start 
 shopping, but I then receive a call from a friend, I hang up, then I forget 
 what I was doing, and launch Angry Birds, and then hey, that's right, I 
 was buying stuff, etc... I go back to the application, and the singletons 
 don't exist anymore.

 Okay, looks like it's a bad idea to use static. But the FAQ is misleading, 
 is it not ? The singletons are not really persistant : Once the order is 
 finished, they are gonna be destroyed straight away.

 I guess that if running the app on api level 14 or more, I could use the 
 onTrimMemory method from the Application class (
 http://developer.android.com/reference/android/app/Application.html#onTrimMemory(int))
  
 to save/serialize my singleton there, and when the application is 
 relaunched, and the singleton is null, restore it.

 But what would be the good/best/not so sucky way to handle with 
 not-really-persistant-but-it-might-be-nice-to-exist-one-hour kind of object 
 ?

 Thanks.


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Handling process killed by system

[Streets Of Boston]

Your app is stateful (state is carried over from Activity to Activity) and 
this is indeed an issue you'll run into. If you want to use a static 
variable (object) for your session state, you'll have to code your own 
persistence.

E.g. 
Access your (global/static) state through a static method (Factory 
pattern). If it is not there, read it from a file or database and then 
return it to the caller.
If it is there, just return it to the caller,

On an Activity's/Fragment's onSaveInstanceState, call a (global/static) 
method that will save your current session state to a file or database. 

Note that saving your session state to a file or database should not happen 
on the main UI thread. You should do it in a background thread. 

You could read your most recent session state from a file/database in your 
Application object's 'onCreate' method. It will start a background thread 
reading the session state and keep a tally when the session state has been 
read successfully or not.

Your Activities that need the session state could use that tally to show a 
'waiting/progress' dialog if the session state is still loading or 
something similar. If/when the session state is loaded, continue with your 
Activity's normal functionality.


On Friday, June 21, 2013 10:52:00 AM UTC-4, Benoit Vermont wrote:

 The problem with parcelable and serializable it that it creates new 
 instance of the object for each Activity that is launched. It means that, 
 every time you leave an Activity, to go back for instance, you will have to 
 write the modified object, and check the onActivityResult each time, to 
 update you current version of the session object. It would not really a 
 Singleton anymore, and therefor is probably not the solution for an 
 instance variable...

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: FragmentManager.popBackStack not working when used with child fragment manager

[Streets Of Boston]

Did a google search and wound up on stackoverflow, where Dianne Hackborn 
answered this question:
http://stackoverflow.com/questions/8772921/how-to-pop-back-stack-for-activity-with-multiple-fragments

In short: The backstack doesn't work for 'inner' fragments, it only works 
for Activity (i.e. 'main') fragments, since the back stack seems to be tied 
to an Activity only, not to its Fragments.

On Saturday, May 25, 2013 9:08:13 AM UTC-4, Miha wrote:

 Hi!

 Starting a new topic from 
 https://groups.google.com/forum/?fromgroups#!topic/android-developers/WgokX2uhv88;
  
 I have a situation where I'm using ViewPager to flip between fragments, and 
 two of the fragments have nested fragments.

 Fragment nesting is done via getChildFragmentManager and orientation 
 changes work as expected (fragments implement onSaveInstanceState), but 
 when trying to pop the backstack after user interactions, I just get a 
 NullPointerException or an IllegalStateException: Activity has been 
 destroyed depending on whether I use popBackStack or popBackStackImmediate.

 If I dump the child fragment state, it shows the activity as detached; If 
 I dump the parent fragment manager state, it shows all of the fragments 
 and also the activity reference (see below).

 I'm using support library, and with that, I'm using classes from 
 android.support.v4.app package.

 Child fragment state:
 FragmentManager misc state:
   mActivity=null
   mContainer=android.support.v4.app.Fragment$1@41603ca0
   mParent=MainFilesFragment{4169ccf0}
   mCurState=0 mStateSaved=false mDestroyed=false

 Parent fragment state:
 Active Fragments in 414896e0:
   #0: null
   #1: ConnectFragment{41505ae0 #1 id=0x7f060001}
 mFragmentId=#7f060001 mContainerId=#7f060001 mTag=null
 mState=5 mIndex=1 mWho=android:fragment:1 mBackStackNesting=0
 mAdded=true mRemoving=false mResumed=true mFromLayout=false 
 mInLayout=false
 mHidden=false mDetached=false mMenuVisible=false mHasMenu=false
 mRetainInstance=false mRetaining=false mUserVisibleHint=false
 mFragmentManager=FragmentManager{414896e0 in MainActivity{41489470}}
 mActivity=com.islonline.isllightdesign.MainActivity@41489470
 mContainer=android.support.v4.view.ViewPager{4145c668 VFED 
  0,0-800,1033 #7f060001 app:id/pager}
 mView=android.support.v4.app.NoSaveStateFrameLayout{414b1258 V.E. 
  800,0-1600,1033}
 mInnerView=android.support.v4.app.NoSaveStateFrameLayout{414b1258 
 V.E.  800,0-1600,1033}
   #2: MainFilesFragment{4155a430 #2 id=0x7f060001}
 mFragmentId=#7f060001 mContainerId=#7f060001 mTag=null
 mState=5 mIndex=2 mWho=android:fragment:2 mBackStackNesting=0
 mAdded=true mRemoving=false mResumed=true mFromLayout=false 
 mInLayout=false
 mHidden=false *mDetached=false* mMenuVisible=true mHasMenu=false
 mRetainInstance=false mRetaining=false mUserVisibleHint=true
 mFragmentManager=FragmentManager{414896e0 in MainActivity{41489470}}
 *mActivity=com.islonline.isllightdesign.MainActivity@41489470*
 mContainer=android.support.v4.view.ViewPager{4145c668 VFED 
  0,0-800,1033 #7f060001 app:id/pager}
 mView=android.support.v4.app.NoSaveStateFrameLayout{4155bcf8 V.E. 
  1600,0-2400,1033}
 mInnerView=android.support.v4.app.NoSaveStateFrameLayout{4155bcf8 
 V.E.  1600,0-2400,1033}
 Child FragmentManager{4155b598 in MainFilesFragment{4155a430}}:
   Active Fragments in 4155b598:
 #0: ComputerListFragment{4155b7b8 #0 id=0x7f060010 COMPUTER_LIST}
   mFragmentId=#7f060010 mContainerId=#7f060010 mTag=COMPUTER_LIST
   mState=1 mIndex=0 mWho=android:fragment:2:0 mBackStackNesting=1
   mAdded=false mRemoving=true mResumed=false mFromLayout=false 
 mInLayout=false
   mHidden=false mDetached=false mMenuVisible=true mHasMenu=false
   mRetainInstance=false mRetaining=false mUserVisibleHint=true
   mFragmentManager=FragmentManager{4155b598 in 
 MainFilesFragment{4155a430}}
   *mActivity=com.islonline.isllightdesign.MainActivity@41489470*
   mParentFragment=MainFilesFragment{4155a430 #2 id=0x7f060001}
   mSavedViewState=android.util.SparseArray@41690a60
 #1: FileShareBrowserFragment{41690840 #1 id=0x7f060010}
   mFragmentId=#7f060010 mContainerId=#7f060010 mTag=null
   mState=5 mIndex=1 mWho=android:fragment:2:1 mBackStackNesting=1
   mAdded=true mRemoving=false mResumed=true mFromLayout=false 
 mInLayout=false
   mHidden=false mDetached=false mMenuVisible=true mHasMenu=false
   mRetainInstance=false mRetaining=false mUserVisibleHint=true
   mFragmentManager=FragmentManager{4155b598 in 
 MainFilesFragment{4155a430}}
   *mActivity=com.islonline.isllightdesign.MainActivity@41489470*
   mParentFragment=MainFilesFragment{4155a430 #2 id=0x7f060001}
   mContainer=android.widget.FrameLayout{4155b210 V.E.  
 

[android-developers] Re: Fragment state (and view) not restored when using ViewPager with nested fragments

[Streets Of Boston]

When using fragments inside a fragment, you should use the fragment's 
ChildFragmentManager and not the (activity's) main FragmentManager. 

On Thursday, May 23, 2013 9:12:31 AM UTC-4, Miha wrote:

 Hi!

 I'm using a ViewPager to swipe between screens. One of the fragments is 
 composed of two fragments, so the hierarchy looks like:

 ViewPager - FragmentStatePageAdapter -  [Frag1, Frag2, Frag3], where 
 Frag1's layout is composed of two FrameLayouts, to which two fragments are 
 added like this:

 if (savedInstanceState != null) {
   FragmentManager supportFragmentManager = 
 getActivity().getSupportFragmentManager(); 
   _computerListFragment = (ComputerListFragment) 
 supportFragmentManager.findFragmentByTag(LIST_FRAGMENT); 
   if (_computerListFragment != null) { 
 _computerListFragment.setOnComputerSelectedListener(this);
   }

   _computerDetailsFragment = (ComputerDetailsFragment) 
 supportFragmentManager.findFragmentByTag(DETAILS_FRAGMENT); 
   if (_computerDetailsFragment != null) { 
 _computerDetailsFragment.setOnComputerDetailsClickListener(this); 
   }

   return root; 
 }

 _computerListFragment = new ComputerListFragment(); 
 FragmentManager supportFragmentManager = 
 getActivity().getSupportFragmentManager(); 
 FragmentTransaction transaction = 
 supportFragmentManager.beginTransaction(); 
 transaction.add(R.id.computer_list_fragment, _computerListFragment, 
 LIST_FRAGMENT); 

 if (_isDualPane) { 
   _computerDetailsFragment = new ComputerDetailsFragment(); 
   
 _computerDetailsFragment.setOnComputerDetailsClickListener(MainComputerFragment.this);
  
   transaction.add(R.id.computer_details_fragment, 
 _computerDetailsFragment, DETAILS_FRAGMENT); 
 } 
 transaction.commit();

 This works well for orientation changes, the fragments get recreated 
 appropriately and onSaveInstanceState gets called for inner fragments 
 (above: ComputerListFragment and ComputerDetailsFragment), but when using 
 ViewPager, I see that:

 1) onSaveInstanceState is called on the First fragment, but not on the 
 inner fragments (in above case, for ComputerListFragment and 
 ComputerDetailsFragment)
 2) trying to call 
 getActivity().getSupportFragmentManager().saveFragmentInstanceState(_computerListFragment);
  
 yields NullPointerException 
 in 
 android.support.v4.app.FragmentManagerImpl.saveFragmentBasicState(FragmentManager.java:1588)
 3) if I try to to add them again, I get an IllegalStateException that the 
 fragment is already added (makes sense)

 It seems to me that I need to tell the fragmentManager that it should save 
 the fragment states, and then to restore them, but I see no appropriate 
 methods for this. It also seems to me that I would need to tell the 
 fragmentManager to show the fragments, since ViewPager obviously removes 
 them somehow...

 Or have I got it backwards somehow?

 Regards,
  Miha.

 ps: I was using ChildFragmentManager at first, but then switched to 
 FragmentManager due to issue I was having. Could this be the case?


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Who's going to AnDevCon V? Discount available. . .

[Streets Of Boston]

I'll be there.
How can i not be there, since I live in Boston. :)

On Thursday, May 2, 2013 4:45:55 PM UTC-4, Nathan wrote:

 Who is going to AnDevCON in Boston this month?

 I will be there speaking at two sessions about Driving App Success. 
 Much smarter people than me also are speaking there. Some of them, you 
 know from this forum. 

 Use the discount code 'MELLOR' to save $20. I f you register before May 
 10, you can save a total of $500.  

 If you do come, I will try to meet you while I am there. 

 Nathan

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Couldn't Create Directory for shared preferences

[Streets Of Boston]

Usually, this is a bug in the OS. Uninstalling and re-installing your app 
can make it go away.

Google 

*android Could n't create Directory for shared preferences*

and you'll find many links/answers/comments on your problem.


On Friday, May 10, 2013 12:34:42 AM UTC-4, rahul wrote:

 Hi Guys,
 I am facing error while trying to create shared preferences from my 
 application
 Could n't create Directory for shared preferences
 Any one face this problem and any known solution for this?

 Thanks alot


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Who's going to AnDevCon V? Discount available. . .

[Streets Of Boston]

I'll be the 6'7 tall Dutch guy in the audience. Usuallly, there are not 
too many of them. :)

https://plus.google.com/107648953926480501831/ 
https://www.facebook.com/streetsofboston

On Friday, May 10, 2013 2:23:17 PM UTC-4, Nathan wrote:



 On Friday, May 10, 2013 11:14:40 AM UTC-7, Streets Of Boston wrote:

 I'll be there.
 How can i not be there, since I live in Boston. :)


 I'll try not to tread on you too heavily, Streets of Boston. 

 You may have to mutate into human form for me to find you.  

 Nathan 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Intent confusion

[Streets Of Boston]

I guess the *Send For Signature *Activity is part of the Adobe Reader 
package/app *com.adobe.reader* as well.

On Friday, May 10, 2013 2:17:05 PM UTC-4, bob wrote:

 I'm trying to understand Intents better.
 So I have this code to show a PDF:
 *String file_loc = /mnt/sdcard/mypdf.pdf;*
 *Uri dest = Uri.fromFile(new File(file_loc));*
 * *
 *Intent i = new Intent();*
 *i.setPackage(com.adobe.reader);*
 *i.setDataAndType(dest, application/pdf);*
 *startActivity(i);*
 I thought it would definitely pop up Adobe Reader, but instead it gives a 
 strange choice:


 https://lh6.googleusercontent.com/-eO6koTVzS3U/UY05mCP0i0I/Adg/PAQSwyBiQ8A/s1600/for_signature.png

 Why does it offer the option Send for Signature?  Shouldn't it know what 
 to do since I specified the exact package name?
 Thanks.
  

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: What methods can be called after Activity.finish() is called?

[Streets Of Boston]

Any listener that listen to events happening on your Views in your Activity 
should cease to receive message-notifications as soon as the Activity and 
its Window (and View hierarchy) are destroyed. 

But if your code or some other code did a postDelayed on the main UI 
Looper, they will be dispatched, activity being destroyed or not. If your 
Runnable, that is posted by calling postDelayed is executed and is still 
referring to a destroyed Activity, you may get into trouble. 

To avoid this, (1) make your Runnable a separate static class and refer to 
the Activity by a WeakReference or  (2) make your Runnable a field/member 
of your Activity and call removeCallbacks on that Runnable field/member in 
your implementation of onDestroy.

On Thursday, April 11, 2013 1:27:47 PM UTC-4, Shri wrote:

 When the currently-resumed Activity finishes itself, onPause and onStop 
 are clearly called. Is there any other code that executes on the Activity 
 or its views? Specifically:

1. Is it possible for any touch events (View#onTouchEvent) to be 
dispatched?
2. Can AnimationListener#onAnimationEnd be called for any animations 
that happenned to be in progress or just terminated? 
3. Can GestureDetector.OnDoubleTapListener.onSingleTapConfirmed be 
called (since it uses a timer to check if a second tap will be received or 
not)?

 I am seeing some rare crashes where it *seems* that these method may be 
 called after finish(). I am not sure about it, but wanted to understand 
 what the model is and what to expect. Unless finish() removes all 
 relevant pending Runnables from the Looper, it seems like any of the above 
 could happen.

 Thanks,
 Shri


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: reusing AsyncTaskLoader with always fresh data

[Streets Of Boston]

The call to getLoaderManager().initLoader(0, args, this);  is enough to 
have your Loader run at least the first time it is created.
Do *not *call 'startLoading()'. 

If you want to refresh your Loader's data call 
getLoaderManager().*restart*Loader(0, 
args, this);

When initLoader or restartLoader is called, the system will call 
onLoadFinished with the data at a later time.


On Wednesday, April 3, 2013 7:28:18 AM UTC-4, Ralph Bergmann wrote:

 Hello, 


 I wont to reuse my AsyncTaskLoader. To do it I call: 

 LoaderResult loader = getLoaderManager().initLoader(0, args, this); 
 loader.startLoading(); 

 In this startLoading method is a if-statment: 

 if (info.mHaveData  mStarted) { 
 // If the loader has already generated its data, report it now. 
 info.callOnLoadFinished(info.mLoader, info.mData); 
 } 
 (
 http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/app/LoaderManager.java#616)
  



 The mStarted flag indicate that the LoaderManager of the activity is 
 started. 

 And the info.mHaveData flag indicate that the loader has data or not 
 from a previous run. 

 My problem / question: How can I reset the loader after a previous run 
 that it lose its data and info.mHaveData is false? Because I get the 
 onLoadFinished call twice and the first one is wrong :-( 


 Ralph 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Activity won't start when launchmode is standard

[Streets Of Boston]

Maybe you could add one more log statement:

Add a default constructor and print a log statement. This would check if 
the DGraphActivity instance is created or not:

public DGraphActivity () {
// Print out a log statement that this code here is reached properly.
}

If this constructor is executed, it means that the system is able to create 
a new DGraphActivity  instance but somehow fails to execute the lifecycle 
events properly.

On Tuesday, April 2, 2013 9:04:19 AM UTC-4, plnelson wrote:


 Here's another detail:If I set  DGraphActivity's launchmode to 
 singleInstance the logcat shows this . . . 

 *03-31 18:49:12.224: I/ActivityManager(119): Starting: Intent { 
 flg=0x400 cmp=com..remote/.DGraphActivity (has extras) } from pid 
 19024

 03-31 18:49:12.298: W/ActivityManager(119): Trying to launch 
 com..remote/.DGraphActivity

 03-31 18:49:12.318: D/DGraphActivity(19024): created*

 But when it's standard it stops at Starting Intent.What does this 
 mean?

 Could someone *please* offer some clues here because I'm totally stumped!



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Debugging the Activity life-cycle?

[Streets Of Boston]

Look at your logcat. It tells you when an activity hasn't started. 
For the onActivityResult getting called instantly: Your returning activity 
was probably started with a singleTask or singleInstance. This means that 
onActivityResult was called immediately after your activity was started 
(and not upon its return). Use default/standard instead.

On Friday, March 29, 2013 4:16:53 PM UTC-4, plnelson wrote:

 Over many projects I've run into various problems with Activities doing 
 mysterious things.   I've had them not start; I've had onActivityResult not 
 get called when I'm trying to send parameters back from an Activity; I've 
 had onActivityResult get called *instantly* before the other Activity 
 even got created.Googling the web I see that lots of people have these 
 problems and often these either stump people on StackOverflow or result in 
 random superstitious fixes with no obvious basis - even if they sometimes 
 seem to work.
  
 So* My Question*:  is there any *systematic* way to debug Activity 
 life-cycle problems - are there log files, traces, dumps, or anything that 
 programmers can use to figure out why something is happening.If I call 
 startActivity and the activity is never created or started, is there 
 anyplace Android tells us why?   If onActivityResult is called prematurely 
 (i.e., before the Activity that's supposed to return the result even 
 exists) how can we find out why it was called? Are there any hints of 
 tricks to interpreting the call stack that can shed light on that?

 Thanks in advance for any tips or tricks.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Activity won't start when launchmode is standard

[Streets Of Boston]

Look at your logcat and see why your activity can't be started. Could be as 
simple as a typo in your manifest.

On Friday, March 29, 2013 4:02:04 PM UTC-4, plnelson wrote:

 This question has (so far)  stumped them on Stack Overflow. . . . 

 I'm trying to launch an Activity which launches *perfectly fine* when its 
 launchMode is set to *singleInstance*. When I change it to *standard*nothing 
 happens; it never gets to onCreate (or onStart or onResume, or 
 anyplace in the target Activity - I've overridden all the lifycycle events 
 and set breakpoints)

 if (DGraphActivity.bitmap != null) {
 Intent intent = new Intent(ctx, DGraphActivity.class);
 intent.putExtra(Buttons, sButtonParam);
 try {
 ctx.startActivity(intent);
 }
 catch (Exception e)  {
 Log.d(Commands, failed to start DGraphActivity);   
 }}   

 in the manifest . . . 

 activity android:name=DGraphActivity
 android:screenOrientation=portrait
 android:launchMode=standard/activity

 I need the DGraphActivity launchMode to be *standard* because it will be 
 launching another activity and using onActivityResult to collect the 
 response and onActivityResult doesn't work with activites launched in 
 singleInstance launchMode. 

 I have lots of other Activities with *standard* launchMode that launch 
 perfectly well, I can't figure out what's different about this one. Thanks 
 in advance!



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Activity won't start when launchmode is standard

[Streets Of Boston]

I've never seen this. If it fails to start, i get a logcat message and an 
exception is thrown (and you are catching that).
Have you tried to set the Intent.FLAG_ACTIVITY_NEW_TASK flag when starting 
the activity?

On Friday, March 29, 2013 6:40:44 PM UTC-4, plnelson wrote:



 On Friday, March 29, 2013 5:57:46 PM UTC-4, Streets Of Boston wrote:

 Look at your logcat and see why your activity can't be started. Could be 
 as simple as a typo in your manifest.


 I only see things in LogCat about  DGraphActivity when it *does* start 
 (ie., when its launchMode is singleInstance).Are you saying there 
 should be a message that it failed to start (or failed to be created)?   I 
 run Logcat with no filters and in verbose mode so I think I'm seeing 
 everything there is.

 The manifest is exactly as it's shown - the *only* difference between the 
 successful case and the failing case is the launchMode, so if there was a 
 typo it would have to be unique to that line.Furthermore it only works 
 for singleInstance, it fails for standard, singleTop and singleTask, so if 
 there was a typo it would have to be in all three of those but not in the 
 singleInstance case.


 RichardC wrote 
   Technically it needs a . here:

   activity android:name=.DGraphActivity

 I'm skeptical.   My program has about 20 Activities and none of them have 
 .'s in front of the name and I've written a lot of other Android programs 
 without .'s.   And this works fine without the . if I launch it in 
 singleInstance.   From time to time I have heard people mention .'s 
 in the Manifest so I don't know if that used to be a requirement in the 
 early days or what.   Just for yucks I tried putting the . in and it 
 didn't help. 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Activity won't start when launchmode is standard

[Streets Of Boston]

Also, change the catching of your try - catch block, so that you see more 
of the exception being thrown when the activity fails to start:

   Log.*e*(Commands, failed to start DGraphActivity*, e*);

This would allow you to see more info of what may go wrong.

On Friday, March 29, 2013 7:04:39 PM UTC-4, Streets Of Boston wrote:

 I've never seen this. If it fails to start, i get a logcat message and an 
 exception is thrown (and you are catching that).
 Have you tried to set the Intent.FLAG_ACTIVITY_NEW_TASK flag when starting 
 the activity?



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Seurity concern in Webview using javascript.

[Streets Of Boston]

As long as your WebView's HTML content doesn't load an external site, i.e. 
you control *all *the content shown in your WebView, there is no concern. 

However, if you make an app that becomes popular and has a WebView that can 
load external/public content, then someone could examine your app, figure 
out what your JavaScriptnterface implements and exploit it for his or her 
own purposes. 

What exactly these vulnerabilities could be, depends entirely on your app 
and its JavaScriptInterface implementation. E.g. if your interface allows 
for the deletion of files or reading and sending of contact information, 
your app is much more vulnerable than when your interface only allows for a 
simple calculation. 



On Wednesday, March 27, 2013 3:59:06 AM UTC-4, Amit Sinha wrote:

 Hi,

 I am creating an android web app using Webview and Java script making 
 addJavascriptInterface(*true*).

 what are the thing i should be taking care so that any malicious 
 code should not run on my app.

 i worried about the security of my app as i am enabling 
 addJavascriptInterface(*true*).

 Please let me know the thing i should do in my app.

 Thanks,
 Amit




-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: How to start again if some third party task killer has killed my app ?

[Streets Of Boston]

You haven't found it, because it doesn't exist :-)

When the OS or a 3rd party app kills your process, it *kills* it 
forcefully. And if your app's process is killed your app no longer runs and 
obviously can't process any callbacks/lifecycle-events, etc. 

On Sunday, March 24, 2013 3:47:17 AM UTC-4, Piren wrote:

 Actually you should take his suggestion, as it can also solve your issue.
 Obviously something is wrong when the app is relaunched, you can use that 
 missing information to understand you need to restart your app (i.e, if 
 it crashes because the user login details are missing, just reset the app 
 instead of crashing). When you see that condition, start your login screen 
 with ClearTop flag (make sure the login screen is SingleInstance). 

 BTW, there is not life cycle event i found that can help you understand an 
 external program is force closing you.

 On Friday, March 22, 2013 8:45:15 AM UTC+2, Amit Dwivedi wrote:

 The question is not limited only about force close errors. It is more 
 about the sudden death of the application which can happen because of so 
 many reasons. In which I want to handle Force close when user goes to the 
 *Settings - Applications - my App* and clicks *Force Close* and When 
 some task killer App *kills* my App.

 By no means I intended to handle Force Close errors generated by some 
 errors / bugs, they must be faced and solved instead of hiding from them.


 On Sat, Dec 29, 2012 at 9:43 PM, Nobu Games dev.nob...@gmail.com wrote:

 I would focus on your force close error and fix that one instead of 
 trying to work around other apps.


 On Thursday, December 27, 2012 12:02:06 AM UTC-6, Amit Dwivedi wrote:

 In my App I have several activities which are obviously related to each 
 other. Whenever I am on some activity and the user kills my app by using 
 any task killer. I want to do two things


1. Clear the Notification which I added when the user logged in..
2. finish all the activities other than the first Activity i.e. 
Login Activity 

 Now if user starts again my app either from the recent tasks or from 
 launcher I want to start from the first activity i.e. Login Activity...

 Presently my code works absolutely fine if I use android *manage 
 process* and end the activity or force close the app from *android 
 task manager*. But if I am using some other task killer app i.e. 
 Advanced task killer, after closing the app when I relaunch the App from 
 recent apps the it tries to restart from the last used Activity instead of 
 Login Activty and gives an ugly force close error and when I click close 
 it 
 redirects me back to Login Activity... The Notification is also not 
 cleared 
 when in this case.

 How do I handle third party task killers ?

 I have read several threads on SO but couldn't get the pointers, few of 
 them are ...

  -- 
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-d...@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en




 -- 
 Thanks  Regards,


 Amit Kumar Dwivedi,https://plus.google.com/u/0/115190842607054249032/posts
  
 Lead Programmer Analyst,
 Argusoft India Ltd.

 Cell No : +91-9714702392 (!dea), +91-9429551692 (BSNL) 
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: Concurrency: Do you use Loaders? AsyncTask? or Runnables?

[Streets Of Boston]

Managed means that a lot of stuff is going on in the background that you 
don't have to worry about. E.g.

   - You don't have to create threads. Just subclass the 
   AsyncTask/Loader/IntentService and implement/override the correct method 
   and your code will run in some background thread.
   You don't have to manage these threads, you don't have to manage sending 
   messages from the background thread(s) to the UI thread and vice versa, 
   etc. You don't have to manage these threads, because code is already 
   implemented for you, e.g. code that creates Threads and stops them, etc. 
   Just read the documentation of AsyncTask/Loader/IntentService and you'll 
   understand a bit more.
   
   - Continuation and result-message delivery.
   A change in configuration is any change to the current state of your 
   phone that may destroy your current Activity and recreates a new instance 
   of it immediately after that. Examples are screen-rotation, keyboard slide 
   in/out, etc.
   When your phone changes configuration (e.g. screen rotation), your 
   Activity and your View hierarchy is usually destroyed (old Activity) and 
   re-created (new Activity in different orientation). If you had some 
   background processes running before the rotation and these are still 
   running after the rotation, you still want your UI to be notified of the 
   background-process' final result. Loaders (used by Fragments) make that a 
   bit easier for you (onLoadFinished callbacks when data loaded by a Loader 
   is ready). 

Note that Runnables are nothing. A Runnable is just a class that implements 
the 'public void run()' method. You probably mean Threads instead. 

On Wednesday, March 20, 2013 2:36:13 PM UTC-4, littledot wrote:

 Thank you all for the kind and enthusiastic responses; they were all very 
 insightful to help my understanding of Android concurrency =D



 In many of these responses, many spoke of threads being *managed* for 
 you.

 This term is very vague to me because in the Ref pages for AsyncTask and 
 Loaders, there are no mentions of how Android manages worker threads during 
 different app lifecycles. 

 http://developer.android.com/reference/android/os/AsyncTask.html
 http://developer.android.com/reference/android/content/Loader.html
 (Ctrl-F  manag  *nothing*)


 In the Loaders API Guide page, it says it helps manage during a 
 configuration change, but what kind of change constitutes a config 
 change? (Maybe after resuming, coming back from a screen lock, change in 
 orientation, etc?)

 http://developer.android.com/guide/components/loaders.html



 *Can you tell me what kind of management support AsyncTasks and Loaders 
 have that are different from Runnables (or that Runnables lack) ?*

 Thank you for reading.



 On Wed, Mar 20, 2013 at 2:15 PM, Kristopher Micinski 
 krismi...@gmail.comjavascript:
  wrote:

 That's what I get for not reading the documentation before speaking. :-) 
 On Mar 20, 2013 12:59 PM, Kristopher Micinski 
 krismi...@gmail.comjavascript: 
 wrote:

 Ah that's right, forgive my comment. 
 On Mar 20, 2013 12:03 PM, Streets Of Boston 
 flying...@gmail.comjavascript: 
 wrote:

 The onStart/onStartCommand methods of a *Service *run in the main UI 
 thread, not a background thread,
 But an *IntentService*'s onHandleIntent method does run in a pooled 
 background thread (pool has only one thread, and subsequent Intents are 
 handled sequentially).


 On Wednesday, March 20, 2013 11:06:05 AM UTC-4, Kristopher Micinski 
 wrote:

 Though it's worth noting that since an `IntentService` doesn't run in 
 a background thread context.  (Probably one of the biggest things 
 beginners screw up..) 

 Kris 

 On Wed, Mar 20, 2013 at 9:49 AM, Streets Of Boston 
 flying...@gmail.com wrote: 
  There are even more ways of doing stuff in the background: 
 IntentService :-) 
  
  Runnable 
  If you mean a Thread (running itself or a Runnable): Generally, 
 avoid using 
  them. But there are good use cases: When you want to setup something 
 that 
  runs in the background for a long time (possible during the entire 
 lifetime 
  of your app's process), simple Threads are very useful, e.g. set up 
 a 
  rendering thread for an openGL game. 
  AsyncTasks 
  If you want to run something in the background, that is a one-shot 
  operation, relatively short duration and you want your UI (main 
 UI-thread) 
  to be notified about updates/results. If you are not worried about 
 screen 
  rotations/config-changes, etc., AsyncTasks work well. AsyncTasks in 
 these 
  situations are relatively simple to implement. 
  Loaders, AsyncTaskLoaders 
  Like AsyncTasks, but they are well suited to easily handle screen 
  rotations/config-changes/etc, especially when used in conjunction 
 with 
  Fragments. 
  IntentService 
  Also good for one-shot operations with relatively short duration. 
 Best used 
  when you want to share these operations among other components of 
 your or 
  other people's

[android-developers] Re: Concurrency: Do you use Loaders? AsyncTask? or Runnables?

[Streets Of Boston]

There are even more ways of doing stuff in the background: IntentService :-)


   - Runnable
   If you mean a Thread (running itself or a Runnable): Generally, avoid 
   using them. But there are good use cases: When you want to setup something 
   that runs in the background for a long time (possible during the entire 
   lifetime of your app's process), simple Threads are very useful, e.g. set 
   up a rendering thread for an openGL game.
   - AsyncTasks
   If you want to run something in the background, that is a one-shot 
   operation, relatively short duration and you want your UI (main UI-thread) 
   to be notified about updates/results. If you are not worried about screen 
   rotations/config-changes, etc., AsyncTasks work well. AsyncTasks in these 
   situations are relatively simple to implement.
   - Loaders, AsyncTaskLoaders
   Like AsyncTasks, but they are well suited to easily handle screen 
   rotations/config-changes/etc, especially when used in conjunction with 
   Fragments.
   - IntentService
   Also good for one-shot operations with relatively short duration. Best 
   used when you want to share these operations among other components of your 
   or other people's applications and/or want to have Android manage its 
   life-cycle (e.g. if an (Intent)Service is killed, Android could restart it 
   for you automatically and re-issue the Intent that started it before). 


On Tuesday, March 19, 2013 8:33:50 PM UTC-4, littledot wrote:

 Android concurrency has always bugged me...

 These are all methods to achieve essentially the same thing: 
 mutli-threading

 *I honestly don't see much difference between them*, except the amount of 
 code you need to write..



 Which methods do you use?

 Are there certain situations where you prefer one method over the other?

 Or do you stick to one method and use it as a rule-of-thumb?



 Thanks for reading.


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: Concurrency: Do you use Loaders? AsyncTask? or Runnables?

[Streets Of Boston]

The onStart/onStartCommand methods of a *Service *run in the main UI 
thread, not a background thread,
But an *IntentService*'s onHandleIntent method does run in a pooled 
background thread (pool has only one thread, and subsequent Intents are 
handled sequentially).


On Wednesday, March 20, 2013 11:06:05 AM UTC-4, Kristopher Micinski wrote:

 Though it's worth noting that since an `IntentService` doesn't run in 
 a background thread context.  (Probably one of the biggest things 
 beginners screw up..) 

 Kris 

 On Wed, Mar 20, 2013 at 9:49 AM, Streets Of Boston 
 flying...@gmail.com javascript: wrote: 
  There are even more ways of doing stuff in the background: IntentService 
 :-) 
  
  Runnable 
  If you mean a Thread (running itself or a Runnable): Generally, avoid 
 using 
  them. But there are good use cases: When you want to setup something 
 that 
  runs in the background for a long time (possible during the entire 
 lifetime 
  of your app's process), simple Threads are very useful, e.g. set up a 
  rendering thread for an openGL game. 
  AsyncTasks 
  If you want to run something in the background, that is a one-shot 
  operation, relatively short duration and you want your UI (main 
 UI-thread) 
  to be notified about updates/results. If you are not worried about 
 screen 
  rotations/config-changes, etc., AsyncTasks work well. AsyncTasks in 
 these 
  situations are relatively simple to implement. 
  Loaders, AsyncTaskLoaders 
  Like AsyncTasks, but they are well suited to easily handle screen 
  rotations/config-changes/etc, especially when used in conjunction with 
  Fragments. 
  IntentService 
  Also good for one-shot operations with relatively short duration. Best 
 used 
  when you want to share these operations among other components of your 
 or 
  other people's applications and/or want to have Android manage its 
  life-cycle (e.g. if an (Intent)Service is killed, Android could restart 
 it 
  for you automatically and re-issue the Intent that started it before). 
  
  
  On Tuesday, March 19, 2013 8:33:50 PM UTC-4, littledot wrote: 
  
  Android concurrency has always bugged me... 
  
  These are all methods to achieve essentially the same thing: 
  mutli-threading 
  
  I honestly don't see much difference between them, except the amount of 
  code you need to write.. 
  
  
  
  Which methods do you use? 
  
  Are there certain situations where you prefer one method over the 
 other? 
  
  Or do you stick to one method and use it as a rule-of-thumb? 
  
  
  
  Thanks for reading. 
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Android Developers group. 
  To post to this group, send email to 
  android-d...@googlegroups.comjavascript: 
  To unsubscribe from this group, send email to 
  android-developers+unsubscr...@googlegroups.com javascript: 
  For more options, visit this group at 
  http://groups.google.com/group/android-developers?hl=en 
  --- 
  You received this message because you are subscribed to the Google 
 Groups 
  Android Developers group. 
  To unsubscribe from this group and stop receiving emails from it, send 
 an 
  email to android-developers+unsubscr...@googlegroups.com javascript:. 
  For more options, visit https://groups.google.com/groups/opt_out. 
  
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: How to get device raw width and height or actual screen width and height ?

[Streets Of Boston]

For any API-level less than 17, use the snippets of code you are using 
successfully now.

For API-level 17 and higher (your Nexus 7 running 4.2), use this:
https://developer.android.com/reference/android/view/Display.html#getRealSize(android.graphics.Point)


On Monday, November 19, 2012 6:29:14 AM UTC-5, Makrand wrote:

 I am trying to get the actual screen width and height of the Nexus 7 
 running on 4.2.

 I am doing some runtime calculations based on device width and height to 
 resize buttons and some UI elements, so it will look proper in all devices. 
 my code was working great in all SDKs 4.1 and below but not working on 4.2.
  
 I am using following code to get width and height. 

 Code: 1
 DisplayMetrics displaymetrics = new DisplayMetrics();
 getWindowManager().getDefaultDisplay().getMetrics(displaymetrics);
 mWidth = displaymetrics.widthPixels;
 mHeight = displaymetrics.heightPixels;

 Code: 2
 Point size = new Point();
 WindowManager w = getWindowManager();
 w.getDefaultDisplay().getSize(size); 
 mWidth = size.x;
 mHeight = size.y;

 I have also tried with undocumented methods 
 Code: 3
 Display display = getWindowManager().getDefaultDisplay();
 Method mGetRawW = Display.class.getMethod(getRawWidth);
 Method mGetRawH = Display.class.getMethod(getRawHeight);
 mWidth = (Integer) mGetRawW.invoke(display);
 mHeight = (Integer) mGetRawH.invoke(display);

 But none of above is working with Nexus 7 running on 4.2, its always 
 subtracting status bar height, I am not getting full height. 

 I have used some methods to calculate status bat height but not getting 
 proper values, 

 int statusBarHeight = Math.ceil(25 * 
 context.getResources().getDisplayMetrics().density);

 AND

 Rect rectgle= new Rect();
 Window window= getWindow();
 window.getDecorView().getWindowVisibleDisplayFrame(rectgle);
 int StatusBarHeight= rectgle.top;

 is there any standard way to get actual device screen height and width?


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Can this variable become null?

[Streets Of Boston]

In addition to Treking's answer;

Never rely on the order in which (you think that) activities are started to 
initialize or modify static/global data. 

E.g.
User goes through your app, starting from the homescreen, going from 
Activity A then to Activity B then to C. This could be order in which the 
activities are created:

A -- B -- C

Now your user presses the Home key and does something else for a while and 
the OS decides to kill your app, because it is in the background.

When the user comes back to your app, this may happen (it depends how your 
activities were launched):
First Activity C is shown, since that was the last one that the user saw. 
When the user now hits the back-button a few times, this could be the order 
in which the activities are created:

C -- B -- A.

Total different order. If your global/static data relies on the activitie's 
creation order, you may run into subtle or not-so-subtle problems.


On Monday, February 25, 2013 11:34:43 AM UTC-5, TreKing wrote:


 On Mon, Feb 25, 2013 at 3:52 AM, user123 ivans...@gmail.com javascript:
  wrote:

 And I'm wondering, if there's any case where I can get a null pointer? 
 Because e.g. the system kills the app while it's in the background, and 
 tries to restart it in the last screen - since the variable is only 
 initialized in the launcher screen, it will not be initialized? Does this 
 case exist?


 To answer your question, yes that exact case does exist, so you don't want 
 to initialize your data in the launcher screen.


 -
 TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago 
 transit tracking app for Android-powered devices
  

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Avoiding the dreaded ANR background work

[Streets Of Boston]

Does your receiver handle the JSON update (i.e. it goes out to the server, 
retrieves the updated json from the server and notifies the registered 
activities)?

If so, this is not correct. BroadcastReceivers should never ever do long 
running tasks. 
Instead, your BroadcastReceiver should receive the synch.my.app request. 
It then would start a Service (preferrably a wakefull IntentService) that 
does the actual work (since IntentServices can run for longer times). The 
IntentService then sends a here.is.the.json broadcast back, when it's 
done, to the registered activities.  

BTW: Instead of sending back here.is.the.json broadcasts, your calling 
Activity could add a ResultReceiver to the Intent. The BroadcastReceiver 
will send the Intent including this ResultReceiver to the IntentService. 
And when the IntentService is done, the IntentService could just call 
'send(resultCode, resultData)' to update the calling Activity of the final 
result. 


On Monday, February 25, 2013 1:25:44 PM UTC-5, stanlick wrote:

 I have been experimenting with an easy way to execute synch type bursts 
 without all the hassle of Services, Loaders, Threads, etc.  I have come up 
 with a technique that works great, but I'd like to get a consensus 
 regarding the pattern.  I am performing sendBroadcast(synch.my.app) from 
 the activity needing an update.  This same activity is registering a 
 broadcast receiver registerReceiver(payload, new 
 IntentFilter(here.is.the.json)) which is being notified from the 
 synch.my.app receiver.  In other words, my broadcastreceiver is calling 
 me back once it has the data.  Is this crazy?  I'm simply poking my json 
 payload into the intent before sending broadcast back to activity.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Binding to Android service in an external jar doesn't seem to be working

[Streets Of Boston]

Maybe this service class uses/loads other classes that fail to load.

Strong candidates that may fail to load are R. classes and their 
members: If your JAR is generatedfrom a library project and if you 
distribute just the JAR file, you may not distribute any R. classes 
along with it, since these are not included in the JAR generation of a 
library project. 

On Monday, February 11, 2013 2:57:54 PM UTC-5, RKSHR wrote:

 I have an external jar file that we have been using to import into an 
 application apk.  Recently I added a Android service class into the jar 
 file, now when I import the file into an apk, I can instantiate all classes 
 except the service. I have declared the service in the applications 
 manifest file (with fully qualified class path), but when I try to bind to 
 the service using context.bindService(intent, connection, 
 BIND_AUTO_CREATE), nothing happens.  I dont get any exception, nor an error 
 message, but service is not instantiated, as the return value for 
 bindService is false.

 I examined the contents of jar file to make sure that the service class is 
 actually included.  I also further dedexd the application dex file and even 
 there the library service class was present. Any ideas what could be the 
 problem? I have read several posts on this, but still unable to figure out 
 the problem.  What I really want to achieve is provide a Android service 
 class in a library (jar file), so application developers can simply bind to 
 the service and it starts the run within the context of the application.  I 
 don't want the service to be remote, hence not using AIDL.  Also the jar is 
 built using ant build.xml, its not marked as a library project, but just as 
 a regular jar file that can be imported into any application.  The goal is 
 to distribute the jar file without the source code, hence not marking it as 
 library.

 RK.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Daemon Threads in Android

[Streets Of Boston]

I agree; Unless your code creates the threads/thread-pools, i.e. if your 
code doesn't own these threads, avoid calling 'setDaemon(...)'. 

On Wednesday, February 6, 2013 8:08:47 PM UTC-5, Nathan wrote:



 On Wednesday, February 6, 2013 4:52:00 PM UTC-8, Streets Of Boston wrote:

 It's mostly just 'ported' from regular Java, where a process could not do 
 a normal 'exit' when non-daemon thread were still running. 
 But you're right. It would seem that if android decides to 'kill' your 
 app, it doesn't much matter whether there are some daemon threads still 
 running or not. 

  

 Still, be on the safe side, don't create these non-daemon thread :-)


 I haven't read anything that encourages developers to set isDaemon() on 
 all their threads, and I don't think it is set by default in ThreadPools, 
 AsyncTask, or in any other commonly used framework classes. 

 So unless you've written your own ThreadPools, etc, I don't think anyone 
 is following that advice. 

 I've run across code that is explicitly calling setDaemon(true). I can't 
 figure out why the developer did that and if it makes any real difference. 
 The developer can't remember either. Even though the developer is me. 

 Nathan 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] ydpi != xdpi

[Streets Of Boston]

Just look here:

http://developer.android.com/reference/android/util/DisplayMetrics.html#density

On Wednesday, February 6, 2013 10:35:52 AM UTC-5, bob wrote:

 Can you please rephrase what you are saying here?  I can't understand it.


 Part of the issue is that a lot of code relies on the density being a 
 single number as shown here:


 https://lh6.googleusercontent.com/-49wC0ys4m0U/URJ4Qj4RRNI/AMQ/-CaNWHHwQ9o/s1600/dpibad3.png






 Also, can someone help me understand how that tool can say that the 
 density is 213 dpi if the xdpi is 195 and the ydpi is 200?


 Thanks.



 On Tuesday, February 5, 2013 3:44:15 PM UTC-6, Romain Guy (Google) wrote:

 There are two ways to have xdpi == ydpi: either your display is square or 
 the display pixels are not square. Why does it make things more complicated?


 On Tue, Feb 5, 2013 at 1:08 PM, bob b...@coolfone.comze.com wrote:

 I think I saw on my Nexus 7 that the ydpi differs from the xdpi.


 Was I imagining or is this really the case with some devices?


 Can someone help me understand why a manufacturer would do such a 
 thing?  It seems like it makes things more complicated with no benefit.


 Thanks.


  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-d...@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups Android Developers group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to android-developers+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




 -- 
 Romain Guy
 Android framework engineer
 roma...@android.com
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Daemon Threads in Android

[Streets Of Boston]

It's mostly just 'ported' from regular Java, where a process could not do a 
normal 'exit' when non-daemon thread were still running. 
But you're right. It would seem that if android decides to 'kill' your app, 
it doesn't much matter whether there are some daemon threads still running 
or not. Still, be on the safe side, don't create these non-daemon thread :-)


On Wednesday, February 6, 2013 7:19:53 PM UTC-5, Nathan wrote:

 I'm just looking at the definition of Thread.isDaemon. 

 It seems like a nice feature. The deamon Thread won't stop the process 
 from exiting. 

 But wait a second. Do non daemon thread stop a process from exiting in 
 Android? I wasn't aware that any thread could stop Android from killing a 
 process anyway. So isDaemon really has no practical meaning in Android. 

 Am I right?

 Nathan

 public final boolean isDaemon ()
 Added in API level 
 1http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 Returns a boolean indicating whether the receiver is a daemon Thread (true) 
 or not (false) A daemon Thread only runs as long as there are non-daemon 
 Threads running. When the last non-daemon Thread ends, the whole program 
 ends no matter if it had daemon Threads still running or not.
 Returns

- a boolean indicating whether the Thread is a daemon

 See Also

- 
 setDaemon(boolean)http://developer.android.com/reference/java/lang/Thread.html#setDaemon(boolean)



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: asynctask vs. FragmentRetainInstance.java in API demo

[Streets Of Boston]

Instead of Threads or AsyncTasks that do the background work getting the 
data from the server, use Loader (AsyncLoader).
You can use the LoaderManager to initially load them and also to restart 
them. Restarting them would allow you to implement your 'refresh' 
functionality.


On Tuesday, February 5, 2013 10:19:52 AM UTC-5, Greenhand wrote:

 As for .. it is unnecessary for a worker fragment to start a asynctask 
 ..., let me put it in another way.
 Yes, I agree a fragment without UI is not a worker thread. Why I said .. 
 it is unnecessary for a worker fragment to start a asynctask ... was about 
 the FragmentRetainInstance.java. It does not start a asynctask; It creates 
 a new thread instead. I hope it is clearer.

 Thank you for giving clear and detailed explanation about how to use a 
 fragment without a UI. I really appreciate it!
  
 With respect to the scenario of adding multiple UI-less fragments to my 
 activity, I would like to use UI-less fragments to perform an HTTP request, 
 such as performing GET request to a RESTful web service. In order to 
 provide the refresh function to users, I need to perform the request again 
 when a corresponding event happens, such as a button click event. I could 
 not figure out another way but only adding the same fragment to my 
 activity. It is why I am concerned about adding multiple UI-less fragements 
 to my activity. Is there another way to do so?
  
 2013/2/5 Streets Of Boston flying...@gmail.com javascript:

 .. it is unnecessary for a worker fragment to start a asynctask ...
 I don't understand the statement above.  A Fragment without a UI is not 
 a worker thread. It is just a Fragment without a UI.

 You can use it to tie data/tasks in the Fragment to the lifecycle of an 
 activity that is hosting the Fragment:

 - If you want your data/tasks to survive configuration changes (e.g. 
 orientation changes) that may destroy and recreate the hosting activity:
 Call 'setRetainInstance(true)' in the onCreate of your Fragment. 
 Destroy/release/stop the data/task in your Fragment when the Fragment's 
 onDestroy is called. This way your Fragment's instance will survive 
 Activity rotations, etc.

 - If your Fragment has data/tasks that can be discarded when the screen 
 (activity) is no longer visible or accessible to the user:
 In the onDetach of your Fragment, destroy/releases/stop the data/task, 
 since the user will no longer be interested in the result of the data/task. 
 Whether you'd like to implement this or not, depends on your app, on the 
 functionality of that screen.

 - You don't need to add multiple UI-less fragments to your activity 
 (depending on your app's needs). One is enough:
 In the onCreate of your activity, user the FragmentManager to see if your 
 Fragment is already there (use the findFragmentBy... methods).
 If it is there, all is fine.
 If it is not there, create a new instance of your UI-less fragment and 
 add/commit it to your activity.
 This makes sure you'll have only one instance of your Fragment that 
 survives orientation changes and such (provided that the 
 setRetainInstance(true) was called in the Fragment's onCreate). 
  



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: startActivity

[Streets Of Boston]

If you want to start one activity (screen) and report a result back to the 
calling activity (screen) you need the handle of the calling activity. No 
way around it.

If you are not worried about reporting a result back, you can get hold of 
the Application Context (context.getApplicationContext()), which is fixed 
in your app's process. Store this Application Context in a global/static 
variable and use it to start new activities.



On Friday, February 1, 2013 4:22:34 PM UTC-5, bob wrote:

 Can someone help me understand why the startActivity method is in the 
 Activity class?

 I really don't feel like it clearly belongs in any class.

 I basically want to call the function when I don't necessarily have a 
 handle to an Activity object yet.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: asynctask vs. FragmentRetainInstance.java in API demo

[Streets Of Boston]

.. it is unnecessary for a worker fragment to start a asynctask ...
I don't understand the statement above.  A Fragment without a UI is not a 
worker thread. It is just a Fragment without a UI.

You can use it to tie data/tasks in the Fragment to the lifecycle of an 
activity that is hosting the Fragment:

- If you want your data/tasks to survive configuration changes (e.g. 
orientation changes) that may destroy and recreate the hosting activity:
Call 'setRetainInstance(true)' in the onCreate of your Fragment. 
Destroy/release/stop the data/task in your Fragment when the Fragment's 
onDestroy is called. This way your Fragment's instance will survive 
Activity rotations, etc.

- If your Fragment has data/tasks that can be discarded when the screen 
(activity) is no longer visible or accessible to the user:
In the onDetach of your Fragment, destroy/releases/stop the data/task, 
since the user will no longer be interested in the result of the data/task. 
Whether you'd like to implement this or not, depends on your app, on the 
functionality of that screen.

- You don't need to add multiple UI-less fragments to your activity 
(depending on your app's needs). One is enough:
In the onCreate of your activity, user the FragmentManager to see if your 
Fragment is already there (use the findFragmentBy... methods).
If it is there, all is fine.
If it is not there, create a new instance of your UI-less fragment and 
add/commit it to your activity.
This makes sure you'll have only one instance of your Fragment that 
survives orientation changes and such (provided that the 
setRetainInstance(true) was called in the Fragment's onCreate). 


On Friday, February 1, 2013 10:18:29 PM UTC-5, Greenhand wrote:

 Thank you for your response. If I use a fragment as a worker thread, I 
 will adapt the pattern in FragmentRetainInstance.java. Because it is 
 unnecessary for a worker fragment to start a asynctask, the worker thread 
 can do the task directly by using java.lang.Thread.
  
 However, I still do not understand whether it is okay to add multiple 
 invisible fragments as worker threads to the UI and why it tries to stop 
 the thread in both onDestroy() and onDetach().

 2013/2/1 Streets Of Boston flying...@gmail.com javascript:

 After your Fragment, the one without a UI, has started the AsyncTask, 
 i.e. after the AsyncTask's 'execute' method has been called, it can stop it 
 by calling 'cancel' on it.


 
 
 task.execute(...);
 ...
 ...


 And on some event, (Fragment's onDestroy for example), you just call.
 task.cancel(true);

 This will remove the task if it was scheduled or, if it is already 
 running, interrupt the thread on which it is running.
 See more info about cancelling 
 herehttps://developer.android.com/reference/android/os/AsyncTask.html#cancel(boolean)
 .

  



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Sending messages to Activity UI thread

[Streets Of Boston]

This is one way of doing it (as long as simHandler was created on UI 
thread).

However, this is too much work.

Just call simHandler.postDelayed on the simHandler itself; no need to 
create a separate thread:
See documentation here:
https://developer.android.com/reference/android/os/Handler.html#postDelayed(java.lang.Runnable,
 
long)


On Monday, February 4, 2013 11:59:10 AM UTC-5, dashman wrote:

 I'd like to send messages to the main UI thread every second.

 This is what I did.

 When I need to start to send messages - I create a Thread
 from the Activity instance. this is what the thread run() method looks 
 like:

 public void run()
 {
 try
 {
 while ( !this.isInterrupted() )
 {
 android.os.Message msg = android.os.Message.obtain( 
 simHandler, 0, simulator );

 simHandler.sendMessage(msg);
 
 this.sleep( 1000 );
 }
 }
 catch ( Exception e )
 {
 }
 }


 then i send a message to a handler - because I want to do the
 work in the UI thread.

 right way?





-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Sending messages to Activity UI thread

[Streets Of Boston]

Yes, you can. Use a WeakReference to your activity.

static class MyHandler extends Handler {
private WeakReferenceMyActivity activityRef;
 public MyHandler(MyActivity activity) {
activityRef = new WeakReferenceMyActivity(activity);
}
 /**
 * @return The activity for which this MyHandler was created.
 * Returns null if this activity is no longer there (i.e. was garbage 
collected).
 */
MyActivity getActivity() {
return activityRef.get();
}
}

Then, you do simHandler= new MyHandler(this);
and when you need the activity:

MyActivity ac = simHandler.getActivity();
if  (ac != null) }


}


On Monday, February 4, 2013 12:29:53 PM UTC-5, dashman wrote:


 ok - i was able to get rid of the thread.

 in the handler - i conditionally call

 this.sendMessageDelayed( android.os.Message.obtain( this, 0, sim ), 1000 );


 next issue.

 i've got the handler defined in the activity class as

 final android.os.Handler simHandler = new android.os.Handler() { ... };

 i get the following warning:

 This Handler class should be static or leaks might occur 
 (com.example.MyActivity.1) 

 If i make it static - i can't call an Activity instance method.











 why in a new Thread? 

 pskink



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: startActivity

[Streets Of Boston]

Yep, it's an override :)

Note that you can't do a 'startActivity*ForResult*' on a regular Context. 
For that, you need an Activity.


On Monday, February 4, 2013 1:49:03 PM UTC-5, bob wrote:

 Oh, I see…  So, startActivity really comes from the Context class?


 I was looking at the docs for Activity, and didn't realize it was an *
 override*.





 On Monday, February 4, 2013 11:07:08 AM UTC-6, Streets Of Boston wrote:

 If you want to start one activity (screen) and report a result back to 
 the calling activity (screen) you need the handle of the calling activity. 
 No way around it.

 If you are not worried about reporting a result back, you can get hold of 
 the Application Context (context.getApplicationContext()), which is fixed 
 in your app's process. Store this Application Context in a global/static 
 variable and use it to start new activities.



 On Friday, February 1, 2013 4:22:34 PM UTC-5, bob wrote:

 Can someone help me understand why the startActivity method is in the 
 Activity class?

 I really don't feel like it clearly belongs in any class.

 I basically want to call the function when I don't necessarily have a 
 handle to an Activity object yet.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Sending messages to Activity UI thread

[Streets Of Boston]

Yep, but you risk a memory leak of your activity, because the Handler 
(being tied to the UI thread which will stick around for a long time) is 
not tied to the life-cycle of your Activity. 


On Monday, February 4, 2013 2:09:35 PM UTC-5, skink wrote:



 Streets Of Boston wrote: 
  Yes, you can. Use a WeakReference to your activity. 
  
  static class MyHandler extends Handler { 
  private WeakReferenceMyActivity activityRef; 
   public MyHandler(MyActivity activity) { 
  activityRef = new WeakReferenceMyActivity(activity); 
  } 
   /** 
   * @return The activity for which this MyHandler was created. 
   * Returns null if this activity is no longer there (i.e. was garbage 
  collected). 
   */ 
  MyActivity getActivity() { 
  return activityRef.get(); 
  } 
  } 
  
  Then, you do simHandler= new MyHandler(this); 
  and when you need the activity: 
  
  MyActivity ac = simHandler.getActivity(); 
  if  (ac != null) } 
   
   
  } 
  
  
  

 imho it's too much hassle. it's better for an Activity to implement 
 Callback iface and create a Handler like this: 

 new Handler(this) 

 where this is an Activity instance 

 pskink 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: asynctask vs. FragmentRetainInstance.java in API demo

[Streets Of Boston]

After your Fragment, the one without a UI, has started the AsyncTask, i.e. 
after the AsyncTask's 'execute' method has been called, it can stop it by 
calling 'cancel' on it.




task.execute(...);
...
...


And on some event, (Fragment's onDestroy for example), you just call.
task.cancel(true);

This will remove the task if it was scheduled or, if it is already running, 
interrupt the thread on which it is running.
See more info about cancelling 
herehttps://developer.android.com/reference/android/os/AsyncTask.html#cancel(boolean)
.



On Wednesday, January 30, 2013 11:30:56 AM UTC-5, Greenhand wrote:

 For asynctask to deal with activity rotation, I find this solution: 
 https://github.com/commonsguy/cw-android/blob/master/Rotation/RotationAsync/src/com/commonsware/android/rotation/async/RotationAsync.java
  .
 However, getlastnonconfigurationinstance() is deprecated in API level 13 (
 http://developer.android.com/reference/android/app/Activity.html#getLastNonConfigurationInstance()
  ) 
 and fragment is recommended.
 I think that fragment is more graceful than asynctask like the code 
 mentioned above in terms of attaching to and detaching from an 
 activity because fragment lifecycles manage them. Besides, fragment can be 
 retained on rotation.
  
 Therefore, I take a look at *
 http://developer.android.com/guide/components/fragments.html*http://developer.android.com/guide/components/fragments.html
  and 
 read For an example activity that uses a fragment as a background worker, 
 without a UI, see the FragmentRetainInstance.java sample. .
 After reading the source code of FragmentRetainInstance.java, I have 
 question on this line 
 getFragmentManager().beginTransaction().add(android.R.id.content, new 
 UiFragment()).commit();.
 It adds the UiFragment()) to the layout and starts the worker thread in 
 RetainedFragment consequently.
  
 I would like to modify the worker thread to perform network operation 
 according to user interaction. For example, when a user fire a 
 View.OnClickListener event, I add the fragment in order to perform network 
 operation.
 Is it okay to add the fragment multiple times if users fire more than one 
 event? Will it lead to some side effect (to view hierarchy)?
  
 The other question, why
 synchronized (mThread) {
 mReady = false;
 mThread.notify();
 }
 appears in both onDestroy() and onDetach()?
 Aren't they duplicate because the thread is gone when onDestroy() returns? 
 Why try to stop the thead again in onDetach()?
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Create bitmap from view but keep view

[Streets Of Boston]

Replied to it on StackOverflow.

On Wednesday, January 23, 2013 9:24:09 PM UTC-5, Caio Ricci wrote:

 I found two ways of creating a Bitmap from a view. But once I do that, the 
 view disappears and I can't use it anymore. How can I redraw the view after 
 generating my bitmap?

 Please check the codes on http://stackoverflow.com/q/14492354/779341

-- 
-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Re: Application.onCreate Method Randomly Called?

[Streets Of Boston]

*SharedPreferences are persistent, assuming that you use commit() or 
apply(). *

Be mindful, though, when different parts of your app are running on 
different processes: If you change some SharedPreferences settings and call 
'commit()' in one process, these changes are not immediately available in 
the other process(es). This may require a restart of the process(es) before 
these changes become known to all the process(es).

On Friday, January 18, 2013 9:09:12 AM UTC-5, Mark Murphy (a Commons Guy) 
wrote:

 On Fri, Jan 18, 2013 at 8:58 AM, Jake Colman col...@ppllc.comjavascript: 
 wrote: 
  When an app get *re*created via a second kills to 
  onCreate (following a kill) does it get the same context? 

 No. Objects cannot live beyond their process, and by definition, your 
 process was terminated. Hence, by definition, all objects in the new 
 process are different instances that any objects from the old process. 

  If that is 
  not guaranteed then should I not be using context-based preferences to 
  persist my data? 

 I have no idea what you consider context-based preferences to be. If 
 you mean static data members, they should be used as a cache for 
 persistent data or for transient purposes only. 

  Is there something other than 
  PreferenceManager.getDefaultSharedPreference to do this? 

 SharedPreferences are persistent, assuming that you use commit() or 
 apply(). 

 -- 
 Mark Murphy (a Commons Guy) 
 http://commonsware.com | http://github.com/commonsguy 
 http://commonsware.com/blog | http://twitter.com/commonsguy 

 Aqui estão alguns sites onde você pode perguntar ou responder dúvidas 
 sobre desenvolvimento de aplicações para Android: 
 http://www.andglobe.com 


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Passing an object as extras in intent

[Streets Of Boston]

If the intent crosses process boundaries and you wrote your own Parcelable, 
be sure to set the ClassLoader on the Bundle  (which represents all the 
Extras in an Intent) before you read the content of the Intent. 

getIntent().getExtras().setClassLoader(getClass().getClassLoader());

On Friday, January 18, 2013 9:48:00 AM UTC-5, a wrote:

 Hi,

 is it possible to pass an object as intent extra in Android? I tried with 
 my class implementing Parcelable and getting a ClassCastException. Can 
 anyone help with an example link?

 Thanks


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Passing an object as extras in intent

[Streets Of Boston]

If your object crosses different packages, look at this post:
http://stackoverflow.com/questions/5743485/android-resultreceiver-across-packages


On Friday, January 18, 2013 10:04:11 AM UTC-5, Streets Of Boston wrote:

 If the intent crosses process boundaries and you wrote your own 
 Parcelable, be sure to set the ClassLoader on the Bundle  (which represents 
 all the Extras in an Intent) before you read the content of the Intent. 

 getIntent().getExtras().setClassLoader(getClass().getClassLoader());

 On Friday, January 18, 2013 9:48:00 AM UTC-5, a wrote:

 Hi,

 is it possible to pass an object as intent extra in Android? I tried with 
 my class implementing Parcelable and getting a ClassCastException. Can 
 anyone help with an example link?

 Thanks



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: SyncAdapter and multiple threads?

[Streets Of Boston]

The answer is right here in the documentation:

https://developer.android.com/reference/android/content/AbstractThreadedSyncAdapter.html#onPerformSync(android.accounts.Account,
 
android.os.Bundle, java.lang.String, android.content.ContentProviderClient, 
android.content.SyncResult)
*... invocations of this method are guaranteed to be serialized.*

and when calling a startSync while another onPerformSync is still busy:

https://developer.android.com/reference/android/content/AbstractThreadedSyncAdapter.html
*...If a sync operation is already in progress when a startSync() request 
is received then an error will be returned to the new request and the 
existing request will be allowed to continue*



On Wednesday, January 16, 2013 10:11:52 AM UTC-5, saladbowl wrote:

 I have created a SyncAdapter class which inherits from 
 AbstractThreadedSyncAdapter and runs in its own Service.

 I was wondering if the SyncManager only allows one synchronisation to be 
 undertaken at a time (i.e via a called to my SyncAdapter's onPerformSync()) 
 or do I need to explicitly make sure my SyncAdapter's onPerformSync() that 
 my data is not corrupted if I two synchronisations happen at the same time?.

 Thanks very much.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: SyncAdapter and multiple threads?

[Streets Of Boston]

The answer is right here in the documentation:

https://developer.android.com/reference/android/content/
AbstractThreadedSyncAdapter.html#onPerformSync(android.accounts.Account, 
android.os.Bundle, java.lang.String, android.content.ContentProviderClient, 
android.content.SyncResult)
*... invocations of this method are guaranteed to be serialized.*

and when calling a startSync while another onPerformSync is still busy:

https://developer.android.com/reference/android/content/AbstractThreadedSyncAdapter.html
*...If a sync operation is already in progress when a startSync() request 
is received then an error will be returned to the new request and the 
existing request will be allowed to continue*

On Wednesday, January 16, 2013 10:11:52 AM UTC-5, saladbowl wrote:

 I have created a SyncAdapter class which inherits from 
 AbstractThreadedSyncAdapter and runs in its own Service.

 I was wondering if the SyncManager only allows one synchronisation to be 
 undertaken at a time (i.e via a called to my SyncAdapter's onPerformSync()) 
 or do I need to explicitly make sure my SyncAdapter's onPerformSync() that 
 my data is not corrupted if I two synchronisations happen at the same time?.

 Thanks very much.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Correct way to implement Activity onDestroy()?

[Streets Of Boston]

An Activity's onDestroy is called all the time (but not every time :)).

It is true that you can't *rely *on it being called, though.

E.g. the onDestroy is always called when you click the 'back' key or do 
some other action (code-execution) that causes the Acitivity's 'finish()' 
method to be called. 

On Monday, January 14, 2013 11:55:10 AM UTC-5, Kristopher Micinski wrote:

 While you say that Activities only die when the process is about to be 
 destroyed (or usually die), I have heard that this is not the case. 
 This is mostly hearsay from developers and people I work with saying 
 that memory leaks because of this were really a problem, but I'd have 
 to look into it with some examples (of layouts that really use memory, 
 I'm thinking galleries and nested views, etc..) before making any 
 definite calls. 

 Kris 

 On Mon, Jan 14, 2013 at 9:37 AM, G. Blake Meike 
 blake...@gmail.comjavascript: 
 wrote: 
  After spending considerable time looking at this issue, I strongly 
 suggest 
  that you look into an Intent Service, for any long running task.  Using 
  AsyncTasks is just fraught. 
  
  First of all, onDestroy is only called best effort.  If you care about 
  getting it done, you can't do it in onDestroy.  Further, as kris points 
 out, 
  onDestroy is, often, called just as your *process* is about to be 
 destroyed. 
  Worrying about allocation of memory in your process, just as it is 
  destroyed, is pretty pointless. 
  
  There are two issues you need to consider: making your program correct 
  according to Java (If mutable state is referenced from more than one 
  thread, all references must take place holding a single lock - B. 
 Goetz, 
  paraphrased).  You also have to be sure that the lifecycles of unmanaged 
  objects (e.g. AsyncTasks) don't interfere with the lifecycles of managed 
  objects (Activities). 
  
  Nulling out pointers and AsyncTasks that survive screen reorientation 
  (despite the fact that I proposed it myself, at one point) are just 
 Voodoo. 
  
  G. Blake Meike 
  Marakana 
  
  Programming Android 2ed is now in stores: 
  http://bit.ly/programmingandroid 
  
  
  On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote: 
  
  Thank you. 
  Another related question, in section 5. Implement a more intelligent 
  AsyncTask dealing with screen orientation of 
  
 http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/,
  

  it has private AsyncTaskComplex activity in ListFresher as a member 
  variable. Shouldn't it be null out because it is not a static Activity 
  references? 
  
  
  Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道： 
  
  Basically, as long as you aren't hanging static Activity references 
  you should be fine.  The main activity will be thrown away upon its 
  destruction, at which point the Activity will be thrown away: along 
  with its contents.  Of course, if you're holding onto Views elsewhere 
  that's bad (i.e., don't hold static refs). 
  
  kris 
  
  On Mon, Jan 14, 2013 at 1:42 AM, Greenhand coopera...@gmail.com 
 wrote: 
   I read 
   
   
 http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html 
   about avoiding memory leaks. 
   I would like to know whether I should null out all member variables, 
   such as 
   TextView and Button in onDestroy()? Or, unregistering listener, 
   unbinding 
   service and etc.in onDestroy() are enough to prevent memory leak? 
   
   -- 
  
  -- 
  You received this message because you are subscribed to the Google 
  Groups Android Developers group. 
  To post to this group, send email to 
  android-d...@googlegroups.comjavascript: 
  To unsubscribe from this group, send email to 
  android-developers+unsubscr...@googlegroups.com javascript: 
  For more options, visit this group at 
  http://groups.google.com/group/android-developers?hl=en 


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: debug blues

[Streets Of Boston]

Yes.

The code on the device (Nexus 7) has debug info that tells Eclipse the 
line-numbers of the source-code. If your source-code (android-16) is 
out-of-date, these line-number don't match up and Eclipse shows you 
something wrong (correct line-number, wrong source-version).

On Thursday, January 10, 2013 10:21:46 AM UTC-5, bob wrote:

 It seems to work if I do Edit Source Lookup and change it to 
 android-17.  Is it 17 because the Nexus 7 is running 4.2.1?


 I built targeted for 16.



 On Wednesday, January 9, 2013 7:46:34 PM UTC-6, RichardC wrote:

 Emulator or Phone and what was the Android version running on it?

 On Wednesday, January 9, 2013 10:40:27 PM UTC, bob wrote:

 I'm stepping thru my source.

 I have a call to invalidate().

 I stepped into it, and attached the android source (version 16).

 However, it went here:

 /**
  * Used to indicate that the parent of this view should be 
 invalidated. This functionality
  * is used to force the parent to rebuild its display list (when 
 hardware-accelerated),
  * which is necessary when various parent-managed properties of the 
 view change, such as
  * alpha, translationX/Y, scrollX/Y, scaleX/Y, and rotation/X/Y. 
 This method will propagate
  * an invalidation event to the parent.
  *
  * @hide
  */
 protected void invalidateParentIfNeeded() {
 if (isHardwareAccelerated()  mParent instanceof View) {
 ((View) mParent).invalidate(true);
 }
 }



 Why did it go to the function *invalidateParentIfNeeded()* instead of 
 the function *invalidate()*?



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: MemoryFile - ParcelFileDescriptor

[Streets Of Boston]

Why are you using a MemoryFile? If you need to read the file into memory, 
you could just use a byte[] and byte-arrays are parcelable.

Actually, I'd suggest not reading it into memory a all and just pass the 
'Uri uri' from the parcelable producer to the consumer and the consumer can 
read the file (as long as the consumer is not a task running on the main UI 
thread).


On Wednesday, July 4, 2012 3:55:32 AM UTC-4, rtindru wrote:

 I have an application that needs to Base64 decode on the fly a bitmap 
 image  render it on the ImageView.
 I am using a custom content provider to do this. When the openFile method 
 is called - I in this case chose to use a normal non-encoded file for 
 testing purpose.
 Now I create a MemoryFile from the imagefile (after decoding)  have to 
 return a ParcelFileDescriptor of the MemoryFile.

 I tried reflection  got the FileDescriptor of the MemoryFile but am 
 unable to get the ParcelFileDescriptor from the FileDescriptor
 I tried the dup, adoptFD methods but the ParcelFileDescriptor was invalid.
 Kindly help me out here.
 Cheers
 Indru

 public ParcelFileDescriptor openFile(Uri uri, String mode)
 throws FileNotFoundException {
 File openFile = new File(uri.toString());
 try {
 MemoryFile file = new MemoryFile(null, (int) 
 openFile.length());
 ParcelFileDescriptor pfd = ParcelFileDescriptor.open(openFile, 
 ParcelFileDescriptor.MODE_READ_ONLY);
 AutoCloseInputStream in = new AutoCloseInputStream(pfd);
 byte[] buffer = new byte[in.available()];
 //Should do decoding here - skipped to test the code
 in.read(buffer, 0, buffer.length);
 file.writeBytes(buffer, 0, 0, buffer.length);
 Method getFileDescriptorMethod = file.getClass().getMethod(
 getFileDescriptor);
 FileDescriptor out = (FileDescriptor) getFileDescriptorMethod
 .invoke(file);
 // I have the FD, now how to return a PFD?? Any ideas? dup  adoptFD dont 
 work - the PFD is invalid.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: MemoryFile - ParcelFileDescriptor

[Streets Of Boston]

Why are you using a MemoryFile? If you need to read the file into memory, 
you could just use a byte[] and byte-arrays are parcelable.

Actually, I'd suggest not reading it into memory a all and just pass the 
'Uri uri' from the parcelable producer process to the consumer process and 
the consumer can read the file.

On Wednesday, July 4, 2012 3:55:32 AM UTC-4, rtindru wrote:

 I have an application that needs to Base64 decode on the fly a bitmap 
 image  render it on the ImageView.
 I am using a custom content provider to do this. When the openFile method 
 is called - I in this case chose to use a normal non-encoded file for 
 testing purpose.
 Now I create a MemoryFile from the imagefile (after decoding)  have to 
 return a ParcelFileDescriptor of the MemoryFile.

 I tried reflection  got the FileDescriptor of the MemoryFile but am 
 unable to get the ParcelFileDescriptor from the FileDescriptor
 I tried the dup, adoptFD methods but the ParcelFileDescriptor was invalid.
 Kindly help me out here.
 Cheers
 Indru

 public ParcelFileDescriptor openFile(Uri uri, String mode)
 throws FileNotFoundException {
 File openFile = new File(uri.toString());
 try {
 MemoryFile file = new MemoryFile(null, (int) 
 openFile.length());
 ParcelFileDescriptor pfd = ParcelFileDescriptor.open(openFile, 
 ParcelFileDescriptor.MODE_READ_ONLY);
 AutoCloseInputStream in = new AutoCloseInputStream(pfd);
 byte[] buffer = new byte[in.available()];
 //Should do decoding here - skipped to test the code
 in.read(buffer, 0, buffer.length);
 file.writeBytes(buffer, 0, 0, buffer.length);
 Method getFileDescriptorMethod = file.getClass().getMethod(
 getFileDescriptor);
 FileDescriptor out = (FileDescriptor) getFileDescriptorMethod
 .invoke(file);
 // I have the FD, now how to return a PFD?? Any ideas? dup  adoptFD dont 
 work - the PFD is invalid.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to avoid useless getView in GridView

[Streets Of Boston]

It probably has something to do with the scrap-head, where recycled views 
are stored.
I wouldn't worry about it too much.

On Monday, January 7, 2013 11:57:04 PM UTC-5, William Guy wrote:

 I have tested GridView  behavior in getView() , and i got:

 01-08 11:18:55.925: E/getView(4113): Position: 0, Child Count: 0, 
 ConvertView: Null
 01-08 11:18:55.945: E/getView(4113): Position: 0, Child Count: 0
 01-08 11:18:55.955: E/getView(4113): Position: 1, Child Count: 1, 
 ConvertView: Null
 01-08 11:18:55.955: E/getView(4113): Position: 2, Child Count: 2, 
 ConvertView: Null
 01-08 11:18:55.955: E/getView(4113): Position: 3, Child Count: 3, 
 ConvertView: Null
 01-08 11:18:55.955: E/getView(4113): Position: 4, Child Count: 4, 
 ConvertView: Null
 01-08 11:18:55.955: E/getView(4113): Position: 5, Child Count: 5, 
 ConvertView: Null
 01-08 11:18:55.965: E/getView(4113): Position: 6, Child Count: 6, 
 ConvertView: Null
 01-08 11:18:55.965: E/getView(4113): Position: 7, Child Count: 7, 
 ConvertView: Null
 01-08 11:18:55.965: E/getView(4113): Position: 8, Child Count: 8, 
 ConvertView: Null
 01-08 11:18:55.965: E/getView(4113): Position: 9, Child Count: 9, 
 ConvertView: Null
 01-08 11:18:55.965: E/getView(4113): Position: 10, Child Count: 10, 
 ConvertView: Null
 01-08 11:18:55.975: E/getView(4113): Position: 11, Child Count: 11, 
 ConvertView: Null
 01-08 11:18:55.975: E/getView(4113): Position: 12, Child Count: 12, 
 ConvertView: Null
 01-08 11:18:55.975: E/getView(4113): Position: 13, Child Count: 13, 
 ConvertView: Null
 01-08 11:18:55.975: E/getView(4113): Position: 14, Child Count: 14, 
 ConvertView: Null
 01-08 11:18:55.975: E/getView(4113): Position: 15, Child Count: 15, 
 ConvertView: Null
 01-08 11:18:55.985: E/getView(4113): Position: 16, Child Count: 16, 
 ConvertView: Null
 01-08 11:18:55.985: E/getView(4113): Position: 17, Child Count: 17, 
 ConvertView: Null
 01-08 11:18:55.985: E/getView(4113): Position: 18, Child Count: 18, 
 ConvertView: Null
 01-08 11:18:55.985: E/getView(4113): Position: 19, Child Count: 19, 
 ConvertView: Null
 01-08 11:18:55.995: E/getView(4113): Position: 0, Child Count: 20, 
 ConvertView: Null
 01-08 11:18:56.065: E/getView(4113): Position: 0, Child Count: 20
 01-08 11:18:56.325: E/getView(4113): Position: 0, Child Count: 20

 There is 20 items in my screen.And only ony GridView in my xml.
 I understand the first getView in position 0 is caused by onMeasure.

 My question is: 
 1. What to lead last three getView in position 0? And why the convert view 
 is null in first one?
 2. How to avoid those case when i setup view holder data in getView?



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to avoid useless getView in GridView?

[Streets Of Boston]

See my answer in your earlier question in this group.

On Tuesday, January 8, 2013 12:04:38 AM UTC-5, William Guy wrote:

 I have tested GridView  behavior in getView, and i got:


 01-08 11:18:55.925: E/getView(4113): Position: 0, Child Count: 0, 
 ConvertView: Null

 01-08 11:18:55.945: E/getView(4113): Position: 0, Child Count: 0

 01-08 11:18:55.955: E/getView(4113): Position: 1, Child Count: 1, 
 ConvertView: Null

 01-08 11:18:55.955: E/getView(4113): Position: 2, Child Count: 2, 
 ConvertView: Null

 01-08 11:18:55.955: E/getView(4113): Position: 3, Child Count: 3, 
 ConvertView: Null

 01-08 11:18:55.955: E/getView(4113): Position: 4, Child Count: 4, 
 ConvertView: Null

 01-08 11:18:55.955: E/getView(4113): Position: 5, Child Count: 5, 
 ConvertView: Null

 01-08 11:18:55.965: E/getView(4113): Position: 6, Child Count: 6, 
 ConvertView: Null

 01-08 11:18:55.965: E/getView(4113): Position: 7, Child Count: 7, 
 ConvertView: Null

 01-08 11:18:55.965: E/getView(4113): Position: 8, Child Count: 8, 
 ConvertView: Null

 01-08 11:18:55.965: E/getView(4113): Position: 9, Child Count: 9, 
 ConvertView: Null

 01-08 11:18:55.965: E/getView(4113): Position: 10, Child Count: 10, 
 ConvertView: Null

 01-08 11:18:55.975: E/getView(4113): Position: 11, Child Count: 11, 
 ConvertView: Null

 01-08 11:18:55.975: E/getView(4113): Position: 12, Child Count: 12, 
 ConvertView: Null

 01-08 11:18:55.975: E/getView(4113): Position: 13, Child Count: 13, 
 ConvertView: Null

 01-08 11:18:55.975: E/getView(4113): Position: 14, Child Count: 14, 
 ConvertView: Null

 01-08 11:18:55.975: E/getView(4113): Position: 15, Child Count: 15, 
 ConvertView: Null

 01-08 11:18:55.985: E/getView(4113): Position: 16, Child Count: 16, 
 ConvertView: Null

 01-08 11:18:55.985: E/getView(4113): Position: 17, Child Count: 17, 
 ConvertView: Null

 01-08 11:18:55.985: E/getView(4113): Position: 18, Child Count: 18, 
 ConvertView: Null

 01-08 11:18:55.985: E/getView(4113): Position: 19, Child Count: 19, 
 ConvertView: Null

 01-08 11:18:55.995: E/getView(4113): Position: 0, Child Count: 20, 
 ConvertView: Null

 01-08 11:18:56.065: E/getView(4113): Position: 0, Child Count: 20

 01-08 11:18:56.325: E/getView(4113): Position: 0, Child Count: 20


 There is 20 items in my screen.And only ony GridView in my xml.

 I understand the first getView in position 0 is caused by onMeasure.

 My question is: 

 1. What to lead last three getView in position 0? And why the convert view 
 is null in first time?

 2. How to avoid those case when i setup view holder data in getView?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: terminating android application

[Streets Of Boston]

First of all: Why?

Secondly: If your process is killed (through a 'kill' command issued, 
through System.exit or Process.killProcess), the OS may restart it (like 
you see sometimes when your app crashes and is starting up immediately 
again with the previous Activity). Also, and this depends on your app''s 
design and purpose, your activity may be hosted inside some other app's 
process. You won't be killing 'your' process but someone else's instead. 

All in all, don't kill your app. *Don't* have an exit button unless you 
have no other option.
http://www.youtube.com/watch?v=631T7B8HOv4


On Wednesday, January 2, 2013 10:21:45 AM UTC-5, laxman k wrote:

 how terminate android application from  any activity and kill background 
 process

 i am use
 finsh();
 system.exit(0);
 System.runFinalizersOnExit(true);
 android.os.Process.killProcess(android.os.Process.myPid());

 these are only close te  current Activity


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Wake locks android

[Streets Of Boston]

In addition to acquiring a partial wake-lock, try to make your service a 
foreground service.
This causes the service to be considered a foreground process and it shows 
the user a notification on the notification bar.
See the method Service#startForeground(int id, Notification not) in the 
api-docs for more info.

Be careful with this, though. Your app may consume more battery power than 
the user would care for.

On Wednesday, December 5, 2012 2:00:27 AM UTC-5, Archana wrote:

 Hi, I m doing it as part of a research project. I need my service to keep 
 running even when the device is asleep(until the user presses Stop button 
 in the App s GUI) and monitor difference in battery consumption. I used 
 PowerManager(implemented WiFi Locks also) because I read that CPU will be 
 ON during this period. When I plug device to the computer, it is working 
 fine. But as soon as it is disconnected, the service seem to stop. I want 
 to know if this is expected behavior? Please guide me in this regard.

 On Tuesday, December 4, 2012 9:08:02 PM UTC+2, G. Blake Meike wrote:

 You probably realize that just seizing a WakeLock for a long time is a 
 really, really horrible idea, yes?  Given that, it isn't clear what you are 
 actually trying to do.  Obviously, your service can't run when the device 
 is asleep

 You can use the Alarm Manager in 
 RTC_WAKEUPhttp://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP
  mode, 
 to cause the device to be awakened, periodically, to run your service.  If 
 you do that, you may have to seize a WakeLock to keep the device awake 
 until your service has completed its task and is ready to let the device go 
 back to sleep...

 G. Blake Meike
 Marakana

 Programming Android 2ed is now in stores:
 http://bit.ly/programmingandroid



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: thread life

[Streets Of Boston]

Yes.

Threads are alive as long as they run and are not at all associated with an 
Activity's (or any other object's) life-cycle.

This is also one of the main reason why it is dangerous to create 
sub-classes of Thread that are (anonymous) non-static inner classes, where 
the outer class is an Activity (or any other object whose life-cycle is 
externally maintained), since instances of these Threads hold implicit 
references to the outer Activity instance -- Activity leak.



On Friday, November 30, 2012 4:10:57 PM UTC-5, bob wrote:

 If you create a Thread in an activity, does it generally live beyond a 
 call to onPause?





-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: extend class and constructors

[Streets Of Boston]

public class Derived extends base
{
public Derived()
{
super();
}

public Derived(int iVal)
{
super(iVal);
}
}

On Thursday, November 29, 2012 12:34:56 PM UTC-5, Simon Giddings wrote:

 This may seem a bit basic, but I come from a C++ background and it is 
 confusing me a little.

 When I extend a base class, do I need to create a constructor for each 
 base class constructor ?
 What I mean is this. Given :

 public class base
 {
 protected int m_iValue;

 public base()
 {
 m_iValue = 0;
 }

 public base(int iVal)
 {
 m_iValue = iVal;
 }
 }

 If I want to create a new class based on this base class, will I need to 
 declare the two constructors again for them to be visible ?
 The following seems to hide the second constructor of the base class.

 public class Derived extends base
 {
 public Derived()
 {
 super();
 }
 }

 What is the correct way to do this ?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Write to another application's internal memory

[Streets Of Boston]

You can't do that.

If you want 2 separate apps (i.e. apps with a different package name and 
therefore different user-ids) to share data, you'd have to device other 
measures:

   1. Write your own ContentProvider that is public/exported.
   
   http://developer.android.com/guide/topics/providers/content-providers.html 
   Both apps can read and write from this and exchange info this way.
   You can implement this ContentProvider in a Project Library used by both 
   your apps.
   
   2. If one app is always sending and the other is always receiving, write 
   your own public/exported Service or a BroadcastReceiver for the receiving 
   app. The sending app can invoke these by sending an Intent 
   (startService/bind or sendBroadcast)
   For extra security, I'd suggest using a BroadcastReceiver using your own 
   homegrown permission.
   
   3. Have the receiving app setup a simple 'Web' Server (listening 
   sockets). 
   Have the other app send data to this socket. 


On Tuesday, November 27, 2012 2:56:27 AM UTC-5, Android Test wrote:

 Hi All,

 I have 2 applications with different package names. E.g. App1 and App2.

 App1 needs to write some files to App2's internal memory so that it could 
 be uploaded to the backend.

 I have used the following in App1 to do so:

 filePath = getPackageManager().getPackageInfo(app2.package.name, 
 0).applicationInfo.dataDir;

 I can get the correct path but could not write to it. I checked the 
 logcat, it is showing Permission denied.

 Am I missing something? What's else needs to be done?

 Thanks in Advance


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Convert a view (layout) to a Bitmap

[Streets Of Boston]

I'm not sure if this will work in your situation, but try 
calling setWillNotCacheDrawing this on the View 'l' as well:

boolean drawsCache = l.willNotCacheDrawing();
l.setWillNotCacheDrawing(false);
Bitmap dragPicture = Bitmap.createBitmap(l.getDrawingCache());
l.setWillNotCacheDrawing(drawsCache);

On Monday, November 17, 2008 5:34:07 AM UTC-5, Jose Cortes wrote:

 Hello everybody. 

 I am working with OpenGL and Android, and I was wondering if there is 
 any way to create a Bitmap or a Drawable using a view (layout). The 
 purpose is to use this Bitmap as Texture for an OpenGL figure. 

 All I have untill now is: 

 ** I create a new view from the context and the Id. 

 View l = new View(context); 

 l.findViewById(R.layout.main); 

 ** I used DrawingCache...but dont know if it is well used: 

 l.setDrawingCacheEnabled(true); 

 Bitmap bmp = l.getDrawingCache(); 

 this bmp is null... 


 Any idea? 

 Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Convert a view (layout) to a Bitmap

[Streets Of Boston]

Hi Justin,

While I do agree that people should not post/answer just anything that they 
have no clue about, you may want to put your foot into your mouth when you 
realize who Romain is :-)

On Saturday, November 17, 2012 3:18:27 PM UTC-5, Justin Buser wrote:

 I don't understand why I keep finding different posts by you 
 about forcing  layout passes.  The View instance this person is referring 
 would never go through a layout pass, regardless of the point at which his 
 code was executed for several reasons, most notably because it's never even 
 added to the display list. Additionally, even if it *was* added to the 
 Window correctly, calling layout() would not force the layout, you would 
 call forceLayout() for that but even that would be pointless because the 
 View doesn't have a layout assigned to it or even have anything to layout 
 in the first place.

 The truly aggravating thing however is the fact that neither the question 
 itself, nor the *actual* answer ever have anything to do with forcing 
 layouts. Do you understand that when other people come across 
 invalid/irrelevant information like this and believe it (if not because you 
 claim to be a developer then simply because they don't know any better) 
 then it's no longer a forgivable case of simply being wrong about 
 something. At that point you are responsible for every adverse reaction 
 your bad information results in. Every application crash/exception 
 thrown/hour lost/dead kitten/etc... that occurs when someone tries your 
 solution and it doesn't work is on your head.

 As a human being you should feel morally obligated to not present anything 
 as fact unless you are 100% confident that it is indeed so. At the very 
 least you should have first hand experience as it pertains to the 
 information you are providing and if not then test / verify it before hand. 
 Although each individual  failure in this may seem relatively 
 insignificant, the aggregate result will ultimately have a negative impact 
 on our evolutionary progress as a species. As far fetched as you may find 
 this to be the vast multitude of problems that threaten our very existence 
 are at some level caused by ignorance, as such it should not be taken 
 lightly at *any* level.

 On Monday, November 17, 2008 11:20:41 AM UTC-5, Romain Guy wrote:

 Hi, 

 If you do this in onCreate(), then the View didn't go through a layout 
 pass yet, so its size is null (0 by 0 pixels.) You need to either wait 
 for the first layout, or force the layout by calling layout() on the 
 View. 

 On Mon, Nov 17, 2008 at 2:34 AM, Jose Cortes jbee...@gmail.com wrote: 
  
  Hello everybody. 
  
  I am working with OpenGL and Android, and I was wondering if there is 
  any way to create a Bitmap or a Drawable using a view (layout). The 
  purpose is to use this Bitmap as Texture for an OpenGL figure. 
  
  All I have untill now is: 
  
  ** I create a new view from the context and the Id. 
  
  View l = new View(context); 
  
  l.findViewById(R.layout.main); 
  
  ** I used DrawingCache...but dont know if it is well used: 
  
  l.setDrawingCacheEnabled(true); 
  
  Bitmap bmp = l.getDrawingCache(); 
  
  this bmp is null... 
  
  
  Any idea? 
  
  Thanks 
   
  



 -- 
 Romain Guy 
 www.curious-creature.org 



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Starting with Loaders, Beginner Questions

[Streets Of Boston]

Some quick answers to your questions :)

1. I use loaders mainly in fragments. Since fragments can be retained 
across configuration changes (setRetainInstance(true)), loaders tied to 
these fragments are retained across configuration changes as well.
Also, delivery to your UI when data has been loaded is handled for you by 
loaders; you don't have to write code checking if the activity still exists 
if the data is delivered, etc. This makes your code less error prone and 
reduces the memory leak of an activity.

2. Initialize the loader in the onCreate (of a Fragment). If the fragment 
is retained, then you shouldn't see an empty list 'flash' when the device 
is rotated: The data from your loader should still be available.

3. Yes, but it depends what object initializes/loads the loader. See my 
previous remarks about using them in fragment that are retained.

4. Using  a ContentObserver/ContentProvider would allow you to easily use 
CursorLoaders.

5. Again: Use a fragment that is retained and that show the 'loading' 
animation:
When starting to load data, set a boolean that is a field in your fragment 
to 'true'.
In onStop stop the loading... animation.
In onStart, if the loading boolean is true, show the animation (again).
When data has been loaded, stop the loading animation and set the loading 
boolean to 'false'.


On Wednesday, November 14, 2012 9:38:15 PM UTC-5, Evan Ruff wrote:

 Hey guys,

 I'm beginning to bring my application out of the dark ages (API 7) up to 
 the more recent stuff and I'd like to migrate from my current Singleton 
 data provider to something like the Loader paradigm. I had a couple of 
 question. Currently, when the Application starts, I pull all of my objects 
 out of the database and hold them in a singleton User object on the 
 Application. The Activities then pass around ID references which query the 
 singleton for values. This breaks down rather dramatically when the 
 application is terminated and doesn't really jive well with the Android 
 way. I've started to do some testing with loaders and have based my test 
 implementation off the follow tutorial:

 http://www.androiddesignpatterns.com/2012/08/implementing-loaders.html

 Couple Questions:
 1. Are loaders special? Are they handled differently from a LifeCycle 
 perspective or is it simply a more streamlined way of doing loading in an 
 AsyncTask then returning it to the Activity?

 2. There always seems to be a nasty flash of an empty list on my 
 Activities. Should the onResume check for a load and load immediately? 
 (deliverResults?)

 3. Do the loaders save state in an onSaveInstanceState sort of way?

 4. I'm a little foggy on the ContentObserver. My data is backed up by the 
 SQLlite DB... is a ContentObserver better, or should I just manually 
 invoke BroadcastReceivers when my application pulls down new data?

 5. How should I handle loading animations in the Activity? Traditional way 
 of start/stopping the Loading animation? My question is around when... 
 show ProgressBar in onResume and hide it on onLoadFinished?

 Thanks for any pointers!

 E


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Starting with Loaders, Beginner Questions

[Streets Of Boston]

reduces the memory leak of an activity.
should read
reduces the *risk of a *memory leak of an activity.

On Thursday, November 15, 2012 9:47:25 AM UTC-5, Streets Of Boston wrote:

 Some quick answers to your questions :)

 1. I use loaders mainly in fragments. Since fragments can be retained 
 across configuration changes (setRetainInstance(true)), loaders tied to 
 these fragments are retained across configuration changes as well.
 Also, delivery to your UI when data has been loaded is handled for you by 
 loaders; you don't have to write code checking if the activity still exists 
 if the data is delivered, etc. This makes your code less error prone and 
 reduces the memory leak of an activity.

 2. Initialize the loader in the onCreate (of a Fragment). If the fragment 
 is retained, then you shouldn't see an empty list 'flash' when the device 
 is rotated: The data from your loader should still be available.

 3. Yes, but it depends what object initializes/loads the loader. See my 
 previous remarks about using them in fragment that are retained.

 4. Using  a ContentObserver/ContentProvider would allow you to easily use 
 CursorLoaders.

 5. Again: Use a fragment that is retained and that show the 'loading' 
 animation:
 When starting to load data, set a boolean that is a field in your fragment 
 to 'true' and show the loading... animation.
 In onStop stop the loading... animation.
 In onStart, if the loading boolean is true, show the loading... animation 
 (again).
 When data has been loaded, stop the loading... animation and set the 
 loading boolean to 'false'.


 On Wednesday, November 14, 2012 9:38:15 PM UTC-5, Evan Ruff wrote:

 Hey guys,

 I'm beginning to bring my application out of the dark ages (API 7) up to 
 the more recent stuff and I'd like to migrate from my current Singleton 
 data provider to something like the Loader paradigm. I had a couple of 
 question. Currently, when the Application starts, I pull all of my objects 
 out of the database and hold them in a singleton User object on the 
 Application. The Activities then pass around ID references which query the 
 singleton for values. This breaks down rather dramatically when the 
 application is terminated and doesn't really jive well with the Android 
 way. I've started to do some testing with loaders and have based my test 
 implementation off the follow tutorial:

 http://www.androiddesignpatterns.com/2012/08/implementing-loaders.html

 Couple Questions:
 1. Are loaders special? Are they handled differently from a LifeCycle 
 perspective or is it simply a more streamlined way of doing loading in an 
 AsyncTask then returning it to the Activity?

 2. There always seems to be a nasty flash of an empty list on my 
 Activities. Should the onResume check for a load and load immediately? 
 (deliverResults?)

 3. Do the loaders save state in an onSaveInstanceState sort of way?

 4. I'm a little foggy on the ContentObserver. My data is backed up by the 
 SQLlite DB... is a ContentObserver better, or should I just manually 
 invoke BroadcastReceivers when my application pulls down new data?

 5. How should I handle loading animations in the Activity? Traditional 
 way of start/stopping the Loading animation? My question is around 
 when... show ProgressBar in onResume and hide it on onLoadFinished?

 Thanks for any pointers!

 E



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: AsyncTask design question

[Streets Of Boston]

Create a separate AsyncTask subclass for each different task that needs to 
be done. 

It is bad Java design to create one large AsyncTask subclass that handles 
everything in your app. That would mean you'd have to create a large 
'doInBackground' method (being able to handle all cases), possibly create a 
large 'onPostExecute' as well, etc, and riddle your code with 'if' 
statements or large 'switch' statements.

In the end, all your AsyncTask instances/objects, regardless which subclass 
they actually are, are run on one 'global' system queue and 'global' pool 
of threads. They all share it. 

For executing a particular AsyncTask instance/object: You can execute an 
AsyncTask instance/object only once (i.e. call 'execute' on the object only 
once). 

--- Anton.

On Tuesday, November 13, 2012 4:44:16 AM UTC-5, Albertus Kruger wrote:

 Hi,

 I am new to Android programming. I would like to know if it is better to 
 have seperate AsyncTasks for every screen on your application or is it 
 better to have one AsynTask class that handles all processing from 
 different screens on my application ?

 I have looked at stackoverflow but its still not clear to me. I'm thinking 
 one class might be a lot of overhead and making seperate AsyncTasks for 
 every screen of my application will be good for performance.

 Thanks for any advice.
 Albertus 


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en