[android-developers] Digest for android-developers@googlegroups.com - 10 Messages in 7 Topics

Comments: (0)

Group: http://groups.google.com/group/android-developers/topics

    Matt <maitrey@rossitek.com> Jul 31 09:06PM -0700  

    Oh ok, so do I need to use something like lazy list or is there any way
    that i can handle it in my code. I am using Fragment Activity and have
    created two fragments and replacing them alternatively for displaying all
    the images one by one.
     
    One more thing that i don't understand is why only on 4.1.2?! I tested the
    application on android 2.3.3, 4.0.3, 4.0.4, 4.1.1, 4.2, also on different
    devices with lower and higher processors, i.e. samsung galaxy s plus,
    galaxy s2, sony xperia tipo, samsung galaxy tab 7 and 10.1. On all the
    devices, it doesn't crash but only on the devices with version 4.1.2.

     

    Kristopher Micinski <krismicinski@gmail.com> Aug 01 12:09AM -0400  

    That's not possible unless you distribute the library as part of the firmware.
     
    Why wouldn't you want the code to be part of the APK? Perhaps there's
    something else you could do.
     
    Kris
     

     

    Streets Of Boston <flyingdutchie@gmail.com> Jul 31 05:42PM -0700  

    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:

     

    Ricardo Cardoso <rick.duk@gmail.com> Jul 31 08:41PM -0300  

    Hello, all right?
    I am using "AndroidAnnotations" in my project and I am having trouble to
    understand this RestTemplate, how do ...
    is this need my Json stay that way:
     
    Parameters: {"user"=>{"email"=>"userTeste@example.com",
    "firstname"=>"anotheruser", "password"=>"[FILTERED]",
    "password_confirmation"=>"[FILTERED]"}, "registration"=>{"user"=>{"email"=>"
    userTeste@example.com", "firstname"=>"anotheruser",
    "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}}}
     
    But my Json being passed as follows
    Parameters: {"dateOfBirth"=>nil, "email"=>"email@gmail.com",
    "firstname"=>"Ricardo", "gender"=>nil, "lastname"=>nil,
    "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]",
    "picture"=>nil, "typeOS"=>nil, "modelPhone"=>nil,
    "registration"=>{"dateOfBirth"=>nil, "email"=>"email@gmail.com",
    "firstname"=>"Ricardo", "gender"=>nil, "lastname"=>nil,
    "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]",
    "picture"=>nil, "typeOS"=>nil, "modelPhone"=>nil}}
     
     
    Is missing the "user" in json ... my code looks like:
    My UserRestClient:
     
    @Rest(rootUrl="http://192.168.1.101:3000",
    converters={MappingJacksonHttpMessageConverter.class})
     
    @Accept(MediaType.APPLICATION_JSON)
     
    public interface UserRestClient {
     
    RestTemplate getRestTemplate();
     
    void setRestTemplate(RestTemplate restTemplate);
     
     
    @Post("/api/v1/registrations")
     
    void addUser(User user);
     
    }
     
    My method that call's my RestClient
     
    @Background
     
    void createAccount(User user) {
     
    try {
     
    userRestClient.addUser(user);
     
    pd.dismiss();
     
    sucessRegister();
     
    } catch (Exception e) {
     
    pd.dismiss();
     
    errorRegister();
     
    }
     
    }
     
    How do I pass this JSON correct?
     
    Hugs

     

    Kostya Vasilyev <kmansoft@gmail.com> Jul 31 03:18PM -0700  

    Since pretty much everyone agrees that the CTS misses things...
     
    Wouldn't it be worthwhile to not only track device specific issues, but to
    also add tests to a fork of CTS?
     
    Google might then accept those enhancement, or might not, it would still be
    helpful in any case.
     
    -- K
     
    On Wednesday, July 31, 2013 9:11:24 PM UTC+4, Kristopher Micinski wrote:

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 12:35PM -0700  

    Just another related thought: SQLiteDatabase contains some implicit
    "transaction magic" under the hood which is meant to prevent "accidents"
    due to simultaneous accesses from different threads. That does not always
    work that great and can lead to some kind of indefinite deadlock situation.
    You can ease that problem by making sure to only give one thread
    "ownership" of the db connection by letting it open and query the
    connection.
     
    You also must make sure not to open the same database connection multiple
    times. In older Android versions that error was not treated gracefully and
    the database file could get corrupted. In newer versions you are greeted
    with an exception. When the database file gets corrupted, the default
    behavior of SQLiteDatabase is "silently" dropping the whole database file
    and creating a new one, so basically you start from scratch in such a
    situation and probably your table creation / setup routines kick in and
    start fresh.
     
     
    On Wednesday, July 31, 2013 2:01:33 PM UTC-5, Nathan wrote:

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 12:33PM -0700  

    Just another related thought: SQLiteDatabase contains some implicit
    "transaction magic" under the hood which is meant to prevent "accidents"
    due to simultaneous accesses from different threads. That does not always
    work that great and can lead to some kind of indefinite deadlock situation.
    You can ease that problem by making sure to only give one thread
    "ownership" of the db connection by letting it open and query the
    connection. You could enforce that by implementing a content provider that
    is only used by your app.
     
    You also must make sure not to open the same database connection multiple
    times. In older Android versions that error was not treated gracefully and
    the database file could get corrupted. In newer versions you are greeted
    with an exception. When the database file gets corrupted, the default
    behavior of SQLiteDatabase is "silently" dropping the whole database file
    and creating a new one, so basically you start from scratch in such a
    situation and probably your table creation / setup routines kick in and
    start fresh.
     
     
     
     
    On Wednesday, July 31, 2013 2:01:33 PM UTC-5, Nathan wrote:

     

    Nathan <nathan.d.mellor@gmail.com> Jul 31 03:01PM -0700  

    On Wednesday, July 31, 2013 12:35:04 PM UTC-7, Nobu Games wrote:
    > You can ease that problem by making sure to only give one thread
    > "ownership" of the db connection by letting it open and query the
    > connection.
     
    A single thread is but there are multiple ones querying .
     

     
    > You also must make sure not to open the same database connection multiple
    > times.
     
    So far, it looks like I am.

     
    > of SQLiteDatabase is "silently" dropping the whole database file and
    > creating a new one, so basically you start from scratch in such a situation
    > and probably your table creation / setup routines kick in and start fresh.
     
    Sounds horrible, and has probably happened to a few unfortunate users.
     
    Nathan

     

    Kostya Vasilyev <kmansoft@gmail.com> Jul 31 03:14PM -0700  

    On Thursday, August 1, 2013 2:01:29 AM UTC+4, Nathan wrote:
    >> creating a new one, so basically you start from scratch in such a situation
    >> and probably your table creation / setup routines kick in and start fresh.
     
    > Sounds horrible, and has probably happened to a few unfortunate users.
     
    Recent Android versions, too, have code to detect database being corrupted
    and then delete and re-create (the database obviously loses all its data).
    I see this happen in my app from time to time -- it's *extremely* rare and
    *extremely* unpleasant to the users. Not sure what the origin of the issue
    is - bugs in SQLite, or maybe flash memory going bad?
     
    As for not opening the same file, have you considered File#getCanonicalPath?
     
    http://developer.android.com/reference/java/io/File.html#getCanonicalFile()
     
    Not sure if it'll properly resolve all those compatibility and profile
    specific memory card paths that ICS/JB have, but perhaps it's worth a try?
     
    -- K

     

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[android-developers] Digest for android-developers@googlegroups.com - 25 Messages in 7 Topics

Comments: (0)

Group: http://groups.google.com/group/android-developers/topics

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 09:21AM -0700  

    How are you handling transactions in your queries? In later versions of
    Android SQLite writes by default temporary "journaling" data files that are
    not immediately merged with the actual database file (see here:
    http://www.sqlite.org/tempfiles.html). This might be an explanation for the
    reported behavior, see the following quote from the SQLite documentation:
     
    However, if the last connection does not shutdown cleanly, the WAL file
    > will remain in the filesystem and will be automatically cleaned up the next
    > time the database is opened.
     
    Other than that, are you sure the path argument is always the same?
     
    On Monday, July 29, 2013 7:00:11 PM UTC-5, Nathan wrote:

     

    Nathan <nathan.d.mellor@gmail.com> Jul 31 12:01PM -0700  

    On Wednesday, July 31, 2013 9:21:59 AM UTC-7, Nobu Games wrote:
     
    > How are you handling transactions in your queries?
     
     
    A single record written is done as a single transaction. I believe, though,
    that the writing part is all done and it is now just reading. No
    transactions on reading.
     

     
     
    > However, if the last connection does not shutdown cleanly, the WAL file
    >> will remain in the filesystem and will be automatically cleaned up the next
    >> time the database is opened.
     
    I would expect some blocking on first open after a crash in that situation.

     
    > Other than that, are you sure the path argument is always the same?
     
    Not completely sure. I want to investigate if there is a possibility of
    getting two paths that are equivalent, yet don't look the same in a string
    compare.
    If so, this code would fail to prevent opening the same file twice in the
    same process.
     
    Nathan

     

    maitrey chhaya <maitrey@rossitek.com> Jul 31 11:53PM +0530  

    Oh ok, so do I need to use something like lazy list or is there any way
    that i can handle it in my code. I am using Fragment Activity and have
    created two fragments and replacing them alternatively for displaying all
    the images one by one.
     
    One more thing that i don't understand is why only on 4.1.2?! I tested the
    application on android 2.3.3, 4.0.3, 4.0.4, 4.1.1, 4.2, also on different
    devices with lower and higher processors, i.e. samsung galaxy s plus,
    galaxy s2, sony xperia tipo, samsung galaxy tab 7 and 10.1. On all the
    devices, it doesn't crash but only on the devices with version 4.1.2.
     
     
     
    --
     
    *Thanks & Regards,**
    *
     
    *Maitrey Chhaya*
     
    *Junior Software Engineer*
     
    * *
     
    *Rossitek Software Solutions*****
     
    *#320/B, Sri Manjunatha Arcade,*
     
    *1st phase, 2nd Stage 40 ft Road.*
     
    *Manjunathnagar, Bangalore-560 010*
     
    *Board Number : ** +91 80 41440617*
     
     
     
    www.rossitek.com <http://www.mavego.com/>****
     
     
     
    *Offshore Mobile & Software Development House*
     
    *IT Capital of India, Bangalore*
     
    *Offshore Development Projects, Teams and Solutions*

     

    maitrey chhaya <maitrey@rossitek.com> Jul 31 11:54PM +0530  

    Oh ok, so do I need to use something like lazy list or is there any way
    that i can handle it in my code. I am using Fragment Activity and have
    created two fragments and replacing them alternatively for displaying all
    the images one by one.
     
    One more thing that i don't understand is why only on 4.1.2?! I tested the
    application on android 2.3.3, 4.0.3, 4.0.4, 4.1.1, 4.2, also on different
    devices with lower and higher processors, i.e. samsung galaxy s plus,
    galaxy s2, sony xperia tipo, samsung galaxy tab 7 and 10.1. On all the
    devices, it doesn't crash but only on the devices with version 4.1.2.
     
     

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 08:25AM -0700  

    I got a big problem with a game of mine and the latest version of Android.
    Semi-transparent pixels rendered on the OpenGL ES surface let the
    underlying activity shine through as following screen shot shows.
     
    This problem only appears in a new "AppGratis" promoted version of the game
    I just released this morning and here is the really bizarre thing: ONLY the
    APK downloaded from Google Play has this problem. When I install the same
    APK that is locally stored on my computer via adb I do not have this
    problem.
    I re-installed the Google Play version multiple times and the rendering
    artifact is always reproducible.
     
    It looks like Google Play alters the APK or maybe it is incorrectly
    installed on the device. However, I do not even know what may trigger that
    "shine through" effect. Any help (especially from Google) appreciated.
     
     
    <https://lh5.googleusercontent.com/-dHoFBBlJjUo/UfkqiTWOIAI/AAAAAAAAADc/PZDIZTdKawQ/s1600/device-2013-07-31-100411.png>

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 09:01AM -0700  

    Tiny update: The SHA1 digest as displayed on the Google Play developer
    console is identical with the one from my uploaded APK on my computer. So I
    just guess that the Google Play app installs things differently or it is a
    really bizarre device quirk. And I do hope it's a rare one because I really
    dread coping with lots of support requests and bad ratings for a problem I
    probably cannot solve on my end.

     

    Romain Guy <romainguy@android.com> Jul 31 10:13AM -0700  

    Is your SurfaceView marked with the transparent pixel format? If so, what
    you are seeing would be expected. If your SurfaceView is opaque then you
    *must* draw every pixel opaque on screen.
     
     
     
    --
    Romain Guy
    Android framework engineer
    romainguy@android.com

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 10:43AM -0700  

    Hi Romain,
     
    thanks for your reply. It seems I do not understand the surface view
    initialization for making the alpha channel within OpenGL ES work. I set up
    the surface view with:
     
    glSurfaceView.getHolder().setFormat(PixelFormat.RGBA_8888);
     
    The game is already out with that surface view setup since May and nobody
    complained about the graphics so far. It also got reviewed with screen
    shots and videos and so on and this artifact is nowhere to be seen.
     
    I also do not understand why there is a difference in rendering between the
    APK downloaded through Google Play and the exact same APK locally installed
    via adb.
     
    Should I change the surface view format to RGB_888 instead?
     
    Regards,
     
    Thomas
     
     
    On Wednesday, July 31, 2013 12:13:51 PM UTC-5, Romain Guy (Google) wrote:

     

    Romain Guy <romainguy@android.com> Jul 31 10:52AM -0700  

    > glSurfaceView.getHolder().setFormat(PixelFormat.RGBA_8888);
     
    This gives you a translucent surface, which means that any pixel that is
    not drawn completely opaque will be blended with whatever window is behind
    your app. It will affect your performance btw.
     
     
    > Should I change the surface view format to RGB_888 instead?
     
    Yes, that will fix your problem and improve perfornance.
     
     
     
    --
    Romain Guy
    Android framework engineer
    romainguy@android.com

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 11:18AM -0700  

    Thanks for the explanation
     
    On Wednesday, July 31, 2013 12:52:14 PM UTC-5, Romain Guy (Google) wrote:

     

    Omer Gilad <omer.gilad@gmail.com> Jul 31 08:06AM -0700  

    I just came upon this by accident
    http://officialandroid.blogspot.co.il/2012/09/the-benefits-importance-of-compatibility.html
     
    This seems like the right approach, but my own experience is that the
    Android reality is very far from this ideal.
     
    I've heard about the CTS.
    The question is - are vendors actually forced to pass the CTS with their
    customizations?
     
    On Friday, July 26, 2013 1:39:14 AM UTC+3, Omer Gilad wrote:

     

    Omer Gilad <omer.gilad@gmail.com> Jul 31 08:10AM -0700  

    I am missing the point of this post.
    Are you saying that there is no solution?
    If so, what do you suggest? Just stop developing for Android?
     
    When I say "not aware of that", I mean that it doesn't show up as a
    practical solution from the eyes of developers.
    Maybe they're aware of that and do internal meetings and discussions about
    it, but it's not something that I know of.
     
    On Wednesday, July 31, 2013 5:43:42 PM UTC+3, a1 wrote:

     

    Omer Gilad <omer.gilad@gmail.com> Jul 31 08:14AM -0700  

    I would certainly support by adding known issues if there was such a system.
    I'm not familiar with any free website that can easily create such a
    database - anyone?
     
    On Wednesday, July 31, 2013 4:59:19 PM UTC+3, Daniele Segato wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 11:17AM -0400  

    Yes. To install Google Play or Google apps, you absolutely are
    required to pass the CTS.
     
    But, from your discussion, the CTS obviously doesn't test all parts of
    the Android platform: it's just a test suite.
     
    Kris
     

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 08:58AM -0700  

    I think a central website for collecting known issues and workarounds would
    be a great idea. There are free wiki hosting services that could be used
    for that: https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services
     
    On Wednesday, July 31, 2013 10:14:40 AM UTC-5, Omer Gilad wrote:

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 09:30AM -0700  

    Oops, I sent my reply just to you, so here again for all to see:
     
    on the one hand that's a good idea. On the other hand we would need someone
    who is willing to host and maintain that bug tracker. Setting up products,
    versions etc. is a lot of work in a bug tracking system. That's why I think
    that a wiki has more chances to "take off" with the majority of Android
    developers as users. There are 10.000-something different Android devices
    out there. It's not much of a problem to introduce new devices in a wiki.
    But it takes a whole deal of dedication for doing that in a bug tracking
    system
     
    On Wednesday, July 31, 2013 11:17:48 AM UTC-5, Daniele Segato wrote:

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 06:36PM +0200  

    Hi Thomas,
     
    The bug trackers I proposed are all free to use and cloud bug trackers
    (meaning no one has to maintain a server or something).
     
    What's needed are admins for that bug tracker.
    Categories can be created when needed.
     
    If there are enough maintainers I think it can be done, the community is
    big and if people really care about this issue I don't think it should
    be a problem to find some.
     
    If they don't really care so much then we will see no one stepping in,
    that's for sure.
     
    regards,
    Daniele Segato
     
    On 07/31/2013 06:30 PM, Nobu Games wrote:

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 06:46PM +0200  

    On 07/31/2013 05:17 PM, Kristopher Micinski wrote:
    > required to pass the CTS.
     
    > But, from your discussion, the CTS obviously doesn't test all parts of
    > the Android platform: it's just a test suite.
     
    Yes, and never will.
     
    It may be a good idea to contact them and ask if they can help in
    setting up a bug database for incompatibilities between different
    android versions.
     
    No idea on how to contact them.

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 01:11PM -0400  

    Just because a test suite doesn't cover all possible behavior doesn't
    mean stricter enforcement wouldn't help developers.
     
    Test suites don't cover all of the codebase by definition, that's why
    they're called test suites :-)
     
    So I'm in favor of setting up a tracker for device bugs, but that
    doesn't also mean that stricter enforcement of bugs couldn't aid
    developers. E.g., to mention one of Omer's points: there could have
    been a CTS test to test the gallery app on that intent. (I believe
    other intents are tested...)
     
    Kris
     
     
    On Wed, Jul 31, 2013 at 12:46 PM, Daniele Segato

     

    Streets Of Boston <flyingdutchie@gmail.com> Jul 31 09:28AM -0700  

    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:

     

    Edvinas Kilbauskas <edvinaskilbauskas@gmail.com> Jul 31 10:06AM -0700  

    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.

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 10:11AM -0700  

    I see in your code sample in your original post that you log the event
    coordinates. That can stall your app and may be a reason for these delays.
    Also, how do you communicate the touch events to your rendering thread?
     
    On Wednesday, July 31, 2013 12:06:22 PM UTC-5, Edvinas Kilbauskas wrote:

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 09:51AM -0700  

    Not that I am in favor of such a behavior but I've seen apps with parental
    control feature doing that. They provide something like a controlled
    sandbox environment as an app (and not as a home screen replacement), so
    children cannot download stuff or do whatever they want with the device.
    Whenever you try to leave the app it pops up again. You can see that in
    action in Famigo.com's app.

     

    Nobu Games <dev.nobu.games@gmail.com> Jul 31 09:32AM -0700  

    As a humble start you could tell us what you tried to do and why exactly it
    doesn't work (error messages etc.). Also be careful with PHP related online
    tutorials. A lot of beginners provide you with material who do not grasp
    basic concepts of code / SQL injection and hardening your web service.
    Maybe you should find a professional PHP developer who codes that for you.
    Shouldn't take too long to implement.
     
    On Sunday, July 28, 2013 4:38:24 AM UTC-5, AndroidYourself wrote:

     

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[android-developers] Digest for android-developers@googlegroups.com - 25 Messages in 6 Topics

Comments: (0)

Group: http://groups.google.com/group/android-developers/topics

    Daniele Segato <daniele.segato@gmail.com> Jul 31 12:40PM +0200  

    On 07/26/2013 12:39 AM, Omer Gilad wrote:
    > .I've decided to move to iOS development, and the only way to convince
    > me otherwise is to give me a decent, reliable way of dealing with
    > fragmentation
     
    [snip]
     
    > How can people stand that?
    > How is it possible to write code, when the machine that executes it is
    > completely broken in unexpected ways?
     
    [snip]
     
    I feel a little put off by this.
     
    Never had issues like the one you describe when doing the things are
    they are supposed to be done (following the docs and guide lines).
     
    When someone talk about fragmentation in Android I laugh. Seriously.
    in iOS if you want to support different device you literary has to
    develop twice. True, they do not have has many devices. But Android is
    designed from the ground to support the fragmentation:
    - you can address different API with just an if in your browser or using
    -v14 in your resources/layouts/values
    - You have fragment and the support library bring backs most of the
    features you need for supporting old devices
     
    Reading your message and the replies you get it seems like everybody is
    experiencing bug in how the API is implemented.
     
    I don't trust you.
    What I think is that either I am be always very lucky either you did
    something wrong.
     
    I'm open to change my mind, but I'd like to have some practical example,
    you seems to have many since you spend most of the time fixing them.
     
    Why don't you share what they are? Maybe you'll discover you are doing
    something you shouldn't or if you are right it could be a start for
    other developers to have a list of gotchas and issues you have to be
    aware off making life easier for everyone.
     
     
    Regards,
    Daniele Segato

     

    Piren <gpiren@gmail.com> Jul 31 04:35AM -0700  

    Either you intentionally ignored the message of his post or you're playing
    dumb.
    No one is complaining about fragmentation (which sucks, but that's besides
    the point).
     
    We're talking about APIs not performing as they should.If you claim that
    this never happened to you, you're either lying, inexperienced, without a
    user base, targeted a single device or haven't used any of the APIs beyond
    doing an app with a single clickable button.
     
    How about you trying writing some code that deals with Bluetooth, Sound,
    Graphics and Sensors (especially the camera) ... run that code on 20
    different devices, then tell us that the APIs are flawless.
     
     
     
    On Wednesday, July 31, 2013 1:40:14 PM UTC+3, Daniele Segato wrote:

     

    Omer Gilad <omer.gilad@gmail.com> Jul 31 04:47AM -0700  

    No problem - you want practical examples, I have literally an endless
    amount...
    I will try not to collapse Google servers or something, so I'll post just a
    few.
     
    By the way - read the original post - I am NOT talking about official
    fragmentation.
    Not screen sizes, API levels features and so on.
    I'm talking about BUGS.
     
    All the issues below were tested with a device in front of me, these are
    not just assumptions.
    Ok, let's go:
     
    1. On Samsung Galaxy S and most of its variants, when you use this simple
    and documented intent:
    http://developer.android.com/guide/topics/media/camera.html#intent-image
     
    The camera app behaves completely differently, and will sometimes ignore
    MediaStore.EXTRA_OUTPUT.
    If you run the same code that would work on any other device, most likely
    you'll crash on a NullPointer, unless you workaround for Samsung.
    Tested with the device in
     
    2. The API AudioManager.setMicrophoneMute
    (http://developer.android.com/reference/android/media/AudioManager.html#setMicrophoneMute(boolean))
    doesn't work at all on some Motorola devices (Milestone variants).
    It will literally do nothing, not mute the mic and even tell that you DID
    mute the mic (isMicrophoneMute will return true after that).
     
    3. Using a GLSL shader with 4x3 matrix multiplication containing some 0's
    on Galaxy S4 will miscalculate the result, and produce artifacts because of
    that.
    Every other device does the same calculation fine, except S4.
     
    4. Using camera preview on some Sony Xperia variants
    (http://developer.android.com/reference/android/hardware/Camera.html#setPreviewCallback(android.hardware.Camera.PreviewCallback))
    will give you flipped or even cut preview frames - so it's completely
    useless for implementing video calling on these devices.
     
    5. Reading from the proximity sensor on Motorola Milestone variants
    (http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_PROXIMITY)
    will give you completely unrelated values, different from every other
    device and ignoring the sensor specification (getMaximumRange() and so on).
     
    6. Running a GLSL shader with 8 varying vectors (the minimum of available
    varying vectors according to the spec., that should be available on every
    device), will cause some Galaxy S variants to reboot instantly.
     
    7. Using an Intent to pick an image from the gallery
    (http://stackoverflow.com/questions/5309190/android-pick-images-from-gallery)
    on some Galaxy S variants will cause the Gallery app to crash.
     
     
    That's just the ones that came to my mind right now.
    I'm sure this can turn into a whole book when other people contribute.
     
    On Wednesday, July 31, 2013 1:40:14 PM UTC+3, Daniele Segato wrote:

     

    Piren <gpiren@gmail.com> Jul 31 05:02AM -0700  

    The Galaxy S (especially the i9000) is one of the shittiest devices i've
    worked on, without a doubt.
     
    On Wednesday, July 31, 2013 2:47:38 PM UTC+3, Omer Gilad wrote:

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 02:32PM +0200  

    On 07/31/2013 01:47 PM, Omer Gilad wrote:
    > amount...
    > I will try not to collapse Google servers or something, so I'll post
    > just a few.
     
    Thanks for that.
     
    > fragmentation.
    > Not screen sizes, API levels features and so on.
    > I'm talking about BUGS.
     
    I got it.
    I'm just saying I never hit one.
    I wrote that message with the specific intent of moving this discussion
    on facts in opposition to "my opinion VS your opinion"
     
    I never said the API are flawless (as Piren pointed out in the other
    response to my message). It's their implementation that may be buggy.
     
    I said my perceiving of the issue is not so bad as you pictured it.
    Maybe 20% of the time for a project may go for fragmentation (both bugs
    and handling API changes, screen sizes etc.).
    I do not often write with native code, Graphics, Bluetooth, Sensors etc.
    Sure, my user bay may not be so big too, sure.
     
    But you know what? I think it's more constructive to list issues and
    try, together as a community, to route them out instead of just wining
    about fragmentation.
    Complaining with Google doesn't help either, because they can't do
    anything about a bug created by someone else.
     
    The only thing you, and all the other hitting this kind of issues can do
    is find a way to list them out. If you really care about the issue you
    should discuss that and put facts (as this list) in front of claims
    (fragmentation sucks).
     
     
    > on some Galaxy S variants will cause the Gallery app to crash.
     
    > That's just the ones that came to my mind right now.
    > I'm sure this can turn into a whole book when other people contribute.
     
    Thank you for this list.
     
    I ask you to avoid the flame and start a constructive discussion instead
    about what we can do, as a community, to help other developers discover
    this kind of issues.
     
    A issue database is what we need.
     
    I don't have the resources to put one up. Probably none of you, alone,
    has them.
     
    my 2 cent
    Cheers,
    Daniele Segato

     

    Kostya Vasilyev <kmansoft@gmail.com> Jul 31 05:37AM -0700  

    The i9000 - oh yeah!
     
    The file system freezes alone were a killer, and then when they implemented
    a "fix", it was preventing apps from saving their own shared preferences.
     
    Today's top of the line Samsung devices seem to be much better (haven't run
    into anything on my Galaxy Note 2, myself, but then I don't develop games),
    but their middle- and low- end devices are still really weird. Just had an
    issue reported for one of them, which I am able to reproduce only on my 2.3
    devices - and this Samsung runs 4.0/4.1. Did they screw up the merge /
    rebase?
     
    -- K
     
    On Wednesday, July 31, 2013 4:02:38 PM UTC+4, Piren wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 08:40AM -0400  

    You're wrong about calling it fragmentation: fragmentation means there
    are n versions of Android, and you have to consider that.
     
    What Omer is saying is that there are actually x >> n "versions" of
    Android, when you take into account all of the vendor ROMs, with their
    long list of bugs.
     
    So it's not about fragmentation, except for in the latter sense.
     
    I also disagree that starting an issue database will help anyone.
    Telling developers to worry about 900 bugs their app may need to worry
    about when they can't test on the individual devices isn't really a
    solution.
     
    Kris
     
    On Wed, Jul 31, 2013 at 8:32 AM, Daniele Segato

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 02:49PM +0200  

    On 07/31/2013 02:40 PM, Kristopher Micinski wrote:
     
    > What Omer is saying is that there are actually x >> n "versions" of
    > Android, when you take into account all of the vendor ROMs, with their
    > long list of bugs.
     
    I know, I just used the term Fragmentation because that's the term Omer
    used ("unofficial" fragmentation) in the first message.
     
    > Telling developers to worry about 900 bugs their app may need to worry
    > about when they can't test on the individual devices isn't really a
    > solution.
     
    Ok, then what you suggest?

     

    Jose_GD <jose.gonzalez.d@gmail.com> Jul 31 05:54AM -0700  

    Daniele, I think Omer has been constructive. He asked clearly: how do you
    deal with this situation? It's obvious there's no bullet proof solution to
    this problem, he has told us what he did until now and asked the community
    what are they doing to deal with it.
     
    El miércoles, 31 de julio de 2013 09:32:41 UTC-3, Daniele Segato escribió:

     

    Omer Gilad <omer.gilad@gmail.com> Jul 31 06:05AM -0700  

    Flaming is not the purpose of this discussion - the purpose is to:
    1. Share and find some practical solutions, if there are any.
    2. Bring the seriousness and span of this issue to Google's attention - as
    there seems to be complete ignorance and self-delusion regarding it.
    So far I haven't seen any official Google source admit that this issue even
    exists, or provide any practical way of dealing with it.
     
    Of course, there's an inevitable element of being completely pissed-off
    about it.
     
     
    Regarding an issue database - that's a partial solution that can certainly
    cut off the amount of work that developers spend on device bugs.
    If I could look up issues related to a specific device or API and prepare
    myself before publishing to users using already made workarounds, maybe my
    job would be easier.
    It will also bring the issue to Google's attention, because at some point
    they'll have to confront a constantly growing device issue database.
     
    But it's only partial - I'm trying to point out the the problem is more in
    the attitude, than in specific device vendors.
    Bugs will always happen in any product, and Google can't put surveillance
    in Samsung's factories and tell them what to do.
    However, Google can be very strict about regulations, and demand high
    standards from anyone who wishes to use the Android brand and use the
    Google Play service.
     
    Some practical steps that Google can take to eliminate the problem that
    developers face when distributing apps:
     
    1. Automatically monitor app ratings in Google Play, and identify spikes
    where a certain device gives a considerably low rating for an app than the
    other devices.
    Chances are that there's a device specific bug.
    Actively inquire the situation ( that will usually apply to lots of apps
    using the same API), and when Google verifies there's indeed a bug in the
    device - demand an on-the-air update from the vendor in 2 weeks.
    If the vendor won't fix the bug on all of its device that can access Google
    Play, ban the device from the store until they fix it.
     
    2. Set up a special contact email for developer reports, so you can get
    reports about specific device issues that developers encounter.
    Do the same procedure like in #1 - ask the vendor to fix it. If they don't
    fix it, remove their Google Play certification until they do.
     
    All that is being asked from Google is to be assertive and strict about who
    they give Google Play certification to.
    I don't expect Google to fix vendor bugs, that's impossible - but I expect
    Google to demand high quality without compromise.
     
    On Wednesday, July 31, 2013 3:32:41 PM UTC+3, Daniele Segato wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 09:10AM -0400  

    I think various people outlined possible solutions if you'd read the
    previous messages. One possible solution is stricter certification
    requirements.
     
    Kris

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 03:12PM +0200  

    On 07/31/2013 03:10 PM, Kristopher Micinski wrote:
    > I think various people outlined possible solutions if you'd read the
    > previous messages. One possible solution is stricter certification
    > requirements.
     
    That's something Google can do, and is probably doing.
     
    I asked what WE can do. If we don't talk about this this whole
    discussion can be trashed, will not be of any help to anyone.

     

    "Παύλος-Πέτρος Τουρνάρης" <p.tournaris@gmail.com> Jul 31 04:36PM +0300  

    I really dont get any of your points Daniele! Every developer that till now
    sent an email in this discussion has already stated his/her opinion in
    order to answer at Omer's first question...
     
    We can bring Google's attetntion at this problem but we should be focused
    on it! If you don't create any workarounds for the buggy devices and just
    ban them from your app, imagine what could happen for those devices..They
    would only be able to download 4-5 apps (just saying...)...
     
     
     
    --
    *Παύλος-Πέτρος Τουρνάρης*
    *Android & Software Developer*
     
    - *http://goo.gl/TsJ8u*
    - *http://acschedule.org*

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 03:34PM +0200  

    On 07/31/2013 03:05 PM, Omer Gilad wrote:
    > Flaming is not the purpose of this discussion - the purpose is to:
    > 1. Share and find some practical solutions, if there are any.
     
    That's the primary reason I bothered to reply in the first place.
    I saw you wasn't try to flame. But, since you were pissed off, you
    missed to actually bring facts to the discussion, which you did later
    replying to me.
     
    Accomplishing that I tough of moving it one step further: from other
    discussion is pretty clear that among who read your question there's no
    one who have a solution.
     
    Every single developer is solo in handling this issue, which is part of
    the reason this is so costly.
     
    If we (all the Android developers) want to achieve this second point:
     
    > as there seems to be complete ignorance and self-delusion regarding it.
    > So far I haven't seen any official Google source admit that this issue
    > even exists, or provide any practical way of dealing with it.
     
    we should keep to the facts, like the list you gave, and start doing
    something.
     
    And I think this discussion is perfect to do some brainstorming of what
    we can do to help everyone.
    It may also help bringing the fact in front of Google to make them
    acknowledge it and help.
     
     
    > Of course, there's an inevitable element of being completely pissed-off
    > about it.
     
    :)
    Know the feeling
     
    > If I could look up issues related to a specific device or API and
    > prepare myself before publishing to users using already made
    > workarounds, maybe my job would be easier.
     
    Yes, better then nothing I think.
    And there are plenty of free bug trackers that can be used too.
     
    > It will also bring the issue to Google's attention, because at some
    > point they'll have to confront a constantly growing device issue database.
     
    Thanks for pointing that out, that's not a small point in building up an
    issue database.
     
    > However, Google can be very strict about regulations, and demand high
    > standards from anyone who wishes to use the Android brand and use the
    > Google Play service.
     
    Agree, and I think they are moving in that direction, but that's my guess.
    Still, it will take time.
    And more importantly, we can't do anything about it now. We may in the
    future if we build that database we were talking about (visibility helps).
     
     
    > Actively inquire the situation ( that will usually apply to lots of apps
    > using the same API), and when Google verifies there's indeed a bug in
    > the device
     
    That would be a good idea.
    And maybe they already do so.
     
    > - demand an on-the-air update from the vendor in 2 weeks.
    > If the vendor won't fix the bug on all of its device that can access
    > Google Play, ban the device from the store until they fix it.
     
    That's probably harder to do.
     
    But as developer we may do something similar... for example by stopping
    supporting very buggy device.
    This is very similar to the InternetExplorer issue web developer have.
    If only Web developer stopped supporting the browser every user would
    just change it.
    If you buy a device for which there are no app you (as an User) say the
    device sucks, not the app.
     
    But if you don't know which devices are more buggy you don't know which
    device to remove the support from --> back to the bugs database.
     
    > reports about specific device issues that developers encounter.
    > Do the same procedure like in #1 - ask the vendor to fix it. If they
    > don't fix it, remove their Google Play certification until they do.
     
    email wouldn't probably be the most useful thing, a dedicated bug
    tracker may be better.
    But that's what Google can do, doesn't help us now.
     
    > who they give Google Play certification to.
    > I don't expect Google to fix vendor bugs, that's impossible - but I
    > expect Google to demand high quality without compromise.
     
    I also expect that. But you can't change the behavior of someone else.
    You can only change your own and hope this will also change the others.
     
    That's some idea:
    - choose and start to use a bug tracker to grow a bug database about
    android personalizations from different vendors
    - create a Google+ Community dedicated to this to have a single place to
    report issues you found out
     
     
    What we need are some people willing to maintain those.
    The more the better.
     
    I've not much experience with these kind of issue, I fear I'll not be
    someone in the right position to do so.
     
    But I'd love to have something like that.
     
    Regards,
    Daniele Segato

     

    Daniele Segato <daniele.segato@gmail.com> Jul 31 03:59PM +0200  

    On 07/31/2013 03:36 PM, Παύλος-Πέτρος Τουρνάρης wrote:
    > I really dont get any of your points Daniele!
     
    I can see that ;)
     
    > Every developer that till
    > now sent an email in this discussion has already stated his/her opinion
    > in order to answer at Omer's first question...
     
    I'm asking you all to think and propose what can be done BY US (not
    Google) to ease up the issue.
    That's it.
     
    And I made a proposal.
     
    > focused on it! If you don't create any workarounds for the buggy devices
    > and just ban them from your app, imagine what could happen for those
    > devices..They would only be able to download 4-5 apps (just saying...)...
     
    That would be absolutely perfect.
    What do you think an user able to download 4-5 apps of that device?
    --> This device sucks
    What will the reviews say about it?
    --> don't buy it
    What will the vendor producing that device do with next devices?
    --> be more complain to the standards.
     
    But hey, that's was just a suggestion on what one can do knowing the
    devices causing more issues.
     
    The main proposal was to put up a bug database for this kind of issues.

     

    a1 <arcone1@gmail.com> Jul 31 07:43AM -0700  


    > 1. Share and find some practical solutions, if there are any.
     
    There isn't any, for some specific use cases (games) best solution is to
    use higher level API (game engine).
     
    2. Bring the seriousness and span of this issue to Google's attention - as
    > there seems to be complete ignorance and self-delusion regarding it.
     
    And you are saying that because of what exactly?

     
    > So far I haven't seen any official Google source admit that this issue
    > even exists, or provide any practical way of dealing with it.
     
    There is no practical way of dealing with it (except of on device basis
    which, according to you, isn't practical), if you search this group and
    stackoverflow you will find several examples where Android team engineers
    talk about device bugs so I really have no idea why you think they aren't
    aware of that, moreover anyone who has ever work with J2ME is more than
    aware that avoiding this is impossible (and J2ME was few orders of
    magnitude worse due to differences in underlying OSes, drivers, CPU
    architectures etc).
     
    --
    Bart

     

    Matt <maitrey@rossitek.com> Jul 31 06:46AM -0700  

    Hi all,
     
    I am loading several images on Fragments. I have about 22 images of total
    2.3 MB. I am getting OutOfMemory error every time I test my app on devices
    with Jelly Bean 4.1.2. The weird thing is, this happens only when I test it
    on devices with Android version 4.1.2. It works fine on any other versions
    on any devices. I am posting my error log here. Please let me know what
    could be wrong:
     
    07-31 14:08:48.688: D/dalvikvm(11970): GC_FOR_ALLOC freed 963K, 42% free
    24641K/41863K, paused 30ms, total 31ms
    07-31 14:08:48.688: I/dalvikvm-heap(11970): Grow heap (frag case) to
    29.015MB for 3932176-byte allocation
    07-31 14:08:48.748: D/dalvikvm(11970): GC_CONCURRENT freed 2170K, 38% free
    26311K/41863K, paused 14ms+5ms, total 60ms
    07-31 14:08:48.803: D/dalvikvm(11970): GC_FOR_ALLOC freed 0K, 38% free
    26311K/41863K, paused 17ms, total 17ms
    07-31 14:08:48.803: I/dalvikvm-heap(11970): Forcing collection of
    SoftReferences for 8847376-byte allocation
    07-31 14:08:48.828: D/dalvikvm(11970): GC_BEFORE_OOM freed 0K, 38% free
    26311K/41863K, paused 25ms, total 25ms
    07-31 14:08:48.828: E/dalvikvm-heap(11970): Out of memory on a 8847376-byte
    allocation.
    07-31 14:08:48.828: I/dalvikvm(11970): "main" prio=5 tid=1 RUNNABLE
    07-31 14:08:48.828: I/dalvikvm(11970): | group="main" sCount=0 dsCount=0
    obj=0x4119c508 self=0x40f509a0
    07-31 14:08:48.828: I/dalvikvm(11970): | sysTid=11970 nice=0 sched=0/0
    cgrp=apps handle=1074540336
    07-31 14:08:48.828: I/dalvikvm(11970): | schedstat=( 14365434265
    4071559868 25502 ) utm=1314 stm=122 core=1
    07-31 14:08:48.828: I/dalvikvm(11970): at
    android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
    07-31 14:08:48.828: I/dalvikvm(11970): at
    android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:625)
    07-31 14:08:48.828: I/dalvikvm(11970): at
    android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:478)
    07-31 14:08:48.828: I/dalvikvm(11970): at
    android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:781)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.content.res.Resources.loadDrawable(Resources.java:1963)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.content.res.Resources.getDrawable(Resources.java:672)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.view.View.setBackgroundResource(View.java:14497)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    com.example.myexample.pages.CoverPage.onActivityCreated(CoverPage.java:46)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.Fragment.performActivityCreated(Fragment.java:1468)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:931)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1088)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.BackStackRecord.run(BackStackRecord.java:682)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1444)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:429)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.os.Handler.handleCallback(Handler.java:615)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.os.Handler.dispatchMessage(Handler.java:92)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.os.Looper.loop(Looper.java:137)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    android.app.ActivityThread.main(ActivityThread.java:4921)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    java.lang.reflect.Method.invokeNative(Native Method)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    java.lang.reflect.Method.invoke(Method.java:511)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1027)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    com.android.internal.os.ZygoteInit.main(ZygoteInit.java:794)
    07-31 14:08:48.833: I/dalvikvm(11970): at
    dalvik.system.NativeStart.main(Native Method)
    07-31 14:08:48.833: A/libc(11970): Fatal signal 11 (SIGSEGV) at 0x00000000
    (code=1), thread 11970 (ple.storybookex)
    07-31 14:08:58.808: E/run(11970): run-runnable

     

    Piren <gpiren@gmail.com> Jul 31 07:04AM -0700  

    Your images are not 2.3MB, their compressed data is... the images when
    loaded by Android are much more than that (their size according to android
    is basically their resolution times the bit depth per pixel you defined).
    The last image you loaded asked for 8.4MB alone...
     
    I assume that you don't actually need to load all those images at the same
    time since you dont have the screen space for that, so load them only when
    they are visible and free them as soon as they are not.
     
    On Wednesday, July 31, 2013 4:46:43 PM UTC+3, Matt wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 08:18AM -0400  

    Heh, this is also a good point, I was dumb not to point the OP in that
    direction sooner :-)
     
     

     

    Piren <gpiren@gmail.com> Jul 31 06:28AM -0700  

    was wondering how you've missed that ;-)
     
    On Wednesday, July 31, 2013 3:18:28 PM UTC+3, Kristopher Micinski wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 31 09:44AM -0400  

    Yeah, that was just me being dumb and writing up a quick response
    without thinking while working on other things. Piren's solution is
    the obvious thing to do: you don't really want to cache hundreds of
    contacts and you'd end up writing your own implementation of what the
    lookup's already doing anyway.
     
    Kris
     

     

    lgaur <lokeshgaur@gmail.com> Jul 31 06:19AM -0700  

    Hi Jelly Chan,
     
    I am trying to compile apk with some jar file and I don't want jar file to
    be part of .apk. I want at runtime apk should take jar file contents or
    .classes from system or device.
     
    I am developing this using ADT . Could you please provide more info how to
    achieve it while using eclipse or ADT ?
     
    Regards
    Lokesh
     
    On Tuesday, January 17, 2012 5:42:48 PM UTC+5:30, Jelly Chen wrote:

     

    Dalvinder Singh <singh.dalvin@gmail.com> Jul 31 03:57PM +0530  

    You are missing
    set flag activity clear top
     
    Read this flag in Intent documentation.
     
    ...
    Dalvinder
     
     
    On Fri, Jul 26, 2013 at 12:50 AM, Amit Mangal
     
    --
    *Cheers*,
    *Dalvinder Singh* | http://dalvinsingh.blogspot.in/

     

    ashish <ashish.acet@gmail.com> Jul 31 12:43AM -0700  

    Hi,
     
    It is done.
    simply start your activity with flag excludeFromRecents= true and it will
    not show your activity in the home app switcher.
     
    On Monday, July 29, 2013 7:01:58 PM UTC+5:30, ashish wrote:

     

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[android-developers] Digest for android-developers@googlegroups.com - 5 Messages in 1 Topic

Comments: (0)

Group: http://groups.google.com/group/android-developers/topics

    Raghavendra Rao <raghu1082@gmail.com> Jul 31 07:27AM +0530  

    Yes i have.. its showing invocation Targetexception<init>. But the same
    code snippet is working fine when i execute that separately, after
    integrating that with my code its causing this problem

     

    Raghavendra Rao <raghu1082@gmail.com> Jul 31 07:33AM +0530  

    Yes i have.. its showing invocation Targetexception<init>.. The jar file
    e:\android\android-sdk-windows\platforms\android-17\android.jar has no
    source attached. But the same code snippet is working fine when i execute
    that separately, after integrating that with my code its causing this
    problem
     
     

     

    TreKing <trekingapp@gmail.com> Jul 30 09:25PM -0500  


    > Yes i have.. its showing invocation Targetexception<init>.. The jar file
    > e:\android\android-sdk-windows\platforms\android-17\android.jar has no
    > source attached.
     
     
    You should download the android sources so you can step into it.
     
     
    > But the same code snippet is working fine when i execute that separately,
    > after integrating that with my code its causing this problem
     
     
    You need to show a stack trace at least if you want help with an exception.
     
    -------------------------------------------------------------------------------------------------
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices

     

    Raghavendra Rao <raghu1082@gmail.com> Jul 31 08:01AM +0530  

    Hey its working now, actually i missed to initialize the speech variable.
    Thanks
     
     

     

    TreKing <trekingapp@gmail.com> Jul 30 09:52PM -0500  


    > Hey its working now, actually i missed to initialize the speech variable.
    > Thanks
     
     
    Uh huh... when I asked "have you debugged your app" ... this is why. =P
     
    -------------------------------------------------------------------------------------------------
    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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[android-developers] Digest for android-developers@googlegroups.com - 25 Messages in 11 Topics

Comments: (0)

Group: http://groups.google.com/group/android-developers/topics

    Turbo <theothertony@gmail.com> Jul 30 05:44PM -0700  

    Kinda sad the Android Engineers don't seem to browse here much.
     
    This is super old but for posterity and future readers: I was looking
    through some source and wondered about this too and came across this SO
    post that *may* shed some light (could be totally off though as there are
    no docs anywhere about it): http://stackoverflow.com/a/4764749/708906
     
    And from a related SO post someone links this blog post:
    http://blog.elsdoerfer.name/2010/04/08/android2po-managing-android-translations/
     
    The guess seems to be some internal tool used to manage translations.
    *shrug*
     
    On Tuesday, November 24, 2009 12:47:06 AM UTC-8, Ken wrote:

     

    Raghavendra Rao <raghu1082@gmail.com> Jul 31 01:10AM +0530  

    Am trying to implement text to speech its not working properly
     
    below is the code snippet
     
    private void speak()
    {
    String text = getText();
    speech.speak(text, TextToSpeech.QUEUE_ADD, null); //getting null pointer
    exception
    }

     

    TreKing <trekingapp@gmail.com> Jul 30 05:46PM -0500  


    > speech.speak(text, TextToSpeech.QUEUE_ADD, null); //getting null pointer
    > exception
     
     
    Have you debugged your app to determine what is null ... ?
     
    -------------------------------------------------------------------------------------------------
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices

     

    Omer Gilad <omer.gilad@gmail.com> Jul 30 03:38PM -0700  

    Hey Mike I still didn't get answers to my questions about this service...
    What are the remote devices that the code is running on? Do I need to
    instruct a user to install this on his own device?
     
    On Monday, July 29, 2013 8:56:12 PM UTC+3, Mike wrote:

     

    Taylor Ringo <taylorringo@gmail.com> Jul 30 01:39PM -0700  

    Hey,
     
    I'm developing my first Android game, and I was wondering if I have to
    renew my Android Developer Console annualy? I am buying a license next
    month!

     

    TreKing <trekingapp@gmail.com> Jul 30 04:46PM -0500  


    > I'm developing my first Android game, and I was wondering if I have to
    > renew my Android Developer Console annualy? I am buying a license next
    > month!
     
     
    No, it is a one time fee 4 life.
     
    -------------------------------------------------------------------------------------------------
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices

     

    Kristoffer <kris.isak.vvik@gmail.com> Jul 30 01:05AM -0700  

    Hello.
    Thanks for reply.
    I have tryed to look at threads and Heap but i could not find what the
    problem was.
    I will try again if i could find anything.
     
    Den måndagen den 29:e juli 2013 kl. 08:22:12 UTC+2 skrev Kristoffer:

     

    Jonathan S <xfsunoles@gmail.com> Jul 30 01:31PM -0700  

    According to
    http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e153,
    " However, the use of EntityUtils is strongly discouraged unless the
    response entities originate from a trusted HTTP server and are known to be
    of limited length." If you want to read entity content more than once, You
    have to use BufferedHttpEntity to wrap HttpEntity.
     
    On Tuesday, July 30, 2013 4:05:26 AM UTC-4, Kristoffer wrote:

     

    Kristoffer <kris.isak.vvik@gmail.com> Jul 30 02:16PM -0700  

    Hello,
    Thanks for the answer.
    Iam going to rewrite my code and i hope there is some part in the old
    onethat is making this issue, i have never seen this before so i hope its a
    one time only.
    Thanks for your time.
     
    Den måndagen den 29:e juli 2013 kl. 08:22:12 UTC+2 skrev Kristoffer:

     

    shiva pendem <pendem.shiva89@gmail.com> Jul 30 11:27AM -0700  

    HI everyone,
     
     
    i am making an application to get the name of the contact no saved on the
    mobile.
     
    i am using the following code
     
    private class *CallStateListener *extends *PhoneStateListener *{
    private String *displayContacts*(String incomingNumber) {
    ContentResolver cr = ctx.getContentResolver();
    Cursor cur = cr.query(ContactsContract.Contacts.CONTENT_URI,
    null, null, null, null);
    if (cur.getCount() > 0) {
    while (cur.moveToNext()) {
    String id =
    cur.getString(cur.getColumnIndex(ContactsContract.Contacts._ID));
    String name =
    cur.getString(cur.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME));
    if (Integer.parseInt(cur.getString(

    cur.getColumnIndex(ContactsContract.Contacts.HAS_PHONE_NUMBER))) > 0) {
    Cursor pCur = cr.query(
    ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
    null,
    ContactsContract.CommonDataKinds.Phone.CONTACT_ID +" =
    ?",
    new String[]{id}, null);
    while (pCur.moveToNext()) {
    String phoneNo =
    pCur.getString(pCur.getColumnIndex(ContactsContract.CommonDataKinds.Phone.NUMBER));
    if(phoneNo.length()>9&&incomingNumber.length()>9)
    {
    //
    Log.v("Test",phoneNo.substring(phoneNo.length()-10,phoneNo.length())+"
    "+incomingNumber.substring(incomingNumber.length()-10,incomingNumber.length()));

    if(phoneNo.substring(phoneNo.length()-10,phoneNo.length()).equals(incomingNumber.substring(incomingNumber.length()-10,incomingNumber.length())))
    {
    Toast.makeText(ctx, "Name: " + name + ", Phone No: " +
    phoneNo, Toast.LENGTH_SHORT).show();
    Log.v("Test","qualified "+phoneNo+" "+name);
    pCur.close();
    return ""+name;
    }
    }
    }
    pCur.close();
    }
    }
    }
    return "";
    }
    i am calling the *displayContacts() *method with the incoming call no as
    argument
    but its taking about 18 to 29 seconds to get the contact name, some times
    it is taking more than 35 seconds,
     
    can any one suggest me the best way to get the contact names saved in the
    mobile,
    i need to get the contact name in the following manner,
    i have a contact with name as service call and no as 9848012345
    and if i get a call i should get the name in not more than 5 seconds .
     
    if there are any new mechanisms that are used to implement this mechanism
    plese send me the links,
     
    Thanks
    Shiva Shankar,

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 30 02:53PM -0400  

    Why don't you read them into memory when the app starts and cache them
    somewhere?
     
    Kris
     

     

    shiva pendem <pendem.shiva89@gmail.com> Jul 31 12:56AM +0530  

    Hi,
     
    Initiallly thanks for your answer,
     
    can we make a app to automatically update the database of contacts so that
    recently added contacts will also be added,
     
    if yes,
    lease reply me how,
    Thanks
     
     
    Thanks,
    Pendem Shiva Shankar,
    Gtalk:pendem.shiva89,
    msn:shivapendem@live.com,
    Mob:+91-9533024675.
     
     
    On Wed, Jul 31, 2013 at 12:23 AM, Kristopher Micinski <

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 30 04:42PM -0400  

    By "the database" I assume you mean your app. You're afraid that your
    app will cache the contacts and then some of the contacts will be
    stale? I mean, watch the database, and update it with an observer:
    that's exactly what that's designed for.
     
    Kris
     

     

    TreKing <trekingapp@gmail.com> Jul 30 11:33AM -0500  


    > If I manage to get logs from the users, I might know what exception it is.
     
     
    I wouldn't rely on waiting on users to send you anything. Have your app
    automatically send you reports using something like ACRA, then flood your
    app with log that are also sent in your report until you track the issue
    down.
     
    -------------------------------------------------------------------------------------------------
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices

     

    Nathan <nathan.d.mellor@gmail.com> Jul 30 10:17AM -0700  

    On Tuesday, July 30, 2013 9:33:44 AM UTC-7, TreKing wrote:
    > automatically send you reports using something like ACRA, then flood your
    > app with log that are also sent in your report until you track the issue
    > down.
     
    I agree with that advice. I am finding any failure places and am treating
    them as a non fatal exception that should be reported in Crashlytics
    without user intervention.
     
    This probably means that it will take more than one update to fix, but
    that's the breaks.
     
    Nathan

     

    Mark J <ali.blesso@gmail.com> Jul 30 10:46AM -0600  

    Hi There,
     
     
     
    Please let me know if you have someone available for below mention
    requirement.
     
    Send your resume to mark@tekenergyusa.com
     
     
     
    *Position: Sr. Android Developer *
     
    *Location: MO*
     
    *Duration: 6+months*
     
    * *
     
    *Required skills:*
    • Deep and broad Android platform experience
    • 10+ years of software development experience
    • Good handle on OOP, patterns and best practices
     
     
     
    Thanks,
     
    Mark
     
    TekEnergy LLC
     
    mark@tekenergyusa.com

     

    ashish <ashish.acet@gmail.com> Jul 30 02:05AM -0700  

    Hi,
     
    i want to prevent the user to close my application with the
    homebutton+applicationswipe.
     
    On Monday, July 29, 2013 8:50:10 PM UTC+5:30, TreKing wrote:

     

    Kristopher Micinski <krismicinski@gmail.com> Jul 30 09:33AM -0400  

    That sounds equally obnoxious. Why would you want to do that? Why
    should your app be able to essentially take over the user's phone?
     
    Kris
     

     

    TreKing <trekingapp@gmail.com> Jul 30 11:27AM -0500  


    > i want to prevent the user to close my application with the
    > homebutton+applicationswipe.
     
     
    This is intentionally not possible.
     
    -------------------------------------------------------------------------------------------------
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices

     

    Daniele Segato <daniele.segato@gmail.com> Jul 30 06:31PM +0200  

    On 07/30/2013 11:05 AM, ashish wrote:
    > Hi,
     
    > i want to prevent the user to close my application with the
    > homebutton+applicationswipe.
     
    If you ever find a way: you found a bug
    and I really hope they'll fix it in that case.
     
    Whatever you are doing: don't. You are doing it utterly wrong.
     
    As I user, if I click home or the app switcher that's because I want to
    go home or switch app and thus want your app to go in background.
     
    If I'll ever found an app that doesn't let me do that I'll uninstall it
    immediately and give it 1 star with comment: "this app deserve zero
    star, keep away from it"
     
    We don't need your app on the market.
     
    I guess don't use an Android phone and never tried to read the design
    and develop sections here: http://developer.android.com/index.html
     
    Stop writing code and take your time to do that. Do it now before you
    waste any more of your (and users) time.
     
     
     
    Hope I've been transparent enough to make you change your mind.
    Regards,
    Daniele Segato

     

    Pierluigi <pierluigi.failla@gmail.com> Jul 30 06:01AM -0700  

    After the last update to Android 4.3 my OnGoing Notification does not show
    different icons as function of iconLevel. My code (*working with all
    previous Android versions*) is the following:
     
    Notification oNotification = new Notification();
    oNotification.icon = R.drawable.levels;
    oNotification.iconLevel = currentLevel;
    oNotification.when = System.currentTimeMillis();
    oNotification.flags |= Notification.FLAG_ONGOING_EVENT;
    oNotification.flags |= Notification.FLAG_ONLY_ALERT_ONCE;
     
    and currentLevel is a particular value depending by the actual status of
    the app. I tested it on the emulator and on a real Nexus 4 with Android
    4.3, same behavior, the icon is always the default (iconLevel = 0).
     
    Maybe I miss something...
     
    Any hint or suggestion is welcome!

     

    Indicator Veritatis <mej1960@yahoo.com> Jul 30 02:24AM -0700  

    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?
     
    On Saturday, July 27, 2013 2:22:09 AM UTC-7, Edvinas Kilbauskas wrote:

     

    a1 <arcone1@gmail.com> Jul 30 03:22AM -0700  

    > 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.
     
    Really, c'mon there's not even a bit of indication that this lag is caused
    by rendering, I assure you that even lousy Adreno 225 from NA variants of
    S3 is more than capable drawing two small triangles at 60fps even in ES
    1.0. That being said ES 2.0 is of course way to go since ES 1.0 is
    basically dead and deprecated.
     
    To OP:
    First measure what cause delay (measure FPS, check and measure how you
    communicate between UI and GL thread etc) and then try to fix this. You
    cannot optimize without hard data.
     
    --
    Bart

     

    Edvinas Kilbauskas <edvinaskilbauskas@gmail.com> Jul 30 04:14AM -0700  

    > 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,
     
    >> }
     
    >> }
     
    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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.