[android-developers] Re: How to implement multiple Android versions to use different libraries?
Similar to Kostya's suggestion, but requires less knowledge of eclipse/ ant/java; however, it doesn't meet your criteria of I prefer to keep my app in one single project. This is what I came-up with before libraries were available; it's not fully automated. But, if you're old-school like me and host in a unix (Mac OSX, Linux, Cygwin+Windows) like environment, you can setup multiple projects in eclipse for each target, making one project your working/master environment, and the others are just build projects (except for things specific to the target). Files that have no differences and don't have any target differences are symbolicly linked in each target project directory tree. Files that are only different because of target dependencies (most often due to java IMPORTs like R.* for your resources/assets), are the part that require a manual step before you perform a build. I create stream-editor (unix sed commmand) scripts via shell language that I run before a build, it reads the input file from the working/master project and re-writes it in the target directory, I create marker comments in the source file that are keys telling sed what to substitute/delete/etc. I'm sure there is probably a way in eclipse to actually tell eclipse to invoke the script as part of a build, but I've never bothered to go look. This is way more complicated than libraries, but if your background is command-line oriented, it's pretty common-sense and easy. I tried libraries the day they were first available and had too many small issues and re-turned to this method. I suspect most of those issues have been cleared-up, but my methods gives me some flexibility with my source (that I find lacking (!!) in java) because it allows me to modify the source as though the language had a decent pre-processor built into it's definition. Some of the things my scripts modify can probably (??) be worked around with java reflection and such, but my working knowledge of java is not as good as it should be. And I prefer compile/build/static solutions over run-time when ever available. I'm purposely not providing examples because this method should not be used unless you can comfortably implement it from the description provided !! I keep the shell script(s) in the target project tree, but they could just as well be in the master/working project. On Jan 10, 5:18 pm, Kostya Vasilyev kmans...@gmail.com wrote: What I just did in a similar situation, is use additional source folders, thus avoiding excessive use of libraries. I have two versions of the same app: one for Market and one for another store. My source directory structure has: src package org.kman.FooBar.licensing SomeClass.java src-market package org.kman.FooBar.licensing SomeClassFactory.java SomeClass_Market.java src-another-store package org.kman.FooBar.licensing SomeClassFactory.java SomeClass_AnotherStore.java There are two versions of the same class, SomeClassFactory, in either additional sKostyaource folder, under the same name, in the same package, and so I can just do SomeClassFactory.create() in the main body of application code, without worrying about which one it is. The implementation of those factories is different, each instantiating its own subclass of SomeClass - the one for Market or for AnotherStore. Now, the bulid setup: 1) In Eclipse: src-market and src-another-store are added as additional source foldeKostyars in the application project. Then src-another-store has an exclude filter matching everything: **/*.*. This way, both folders are accesible for browsing / editing / source control, but only the sources inside src-market are compiled. 2) For command line builds: I have a modified build.xml, and use sourcepathref with javac when compiling, to supply one or the other additional source folder, depending on which version I'm building. This additional path reference is set by a task that executes early in the ant build setup sequence, and makes the decision based on a property passed into the build script with -Dbuildtype=market or -Dbuildtype=anotherstore on the ant command line. Finally, there are two very simple shell scripts that call ant with the appropriate -D... flags.The shell script(s) End result: - The sources for both versions are accessible in Eclipse - The app can be built in Eclipse, defaulting to one of the two possiblebut when faced with spending my time learning features of java that aren't really necessary configurations - The main body of application code is not in a library, but rather a regular application project so my change-compile-debug cycles are faster (I think) - Clean command line builds are just a simple shell command away, for either configuration - The Market version doesn't contain any code for the alternate store, and vice versa. - Command line builds name the build output with a suffix, something like
[android-developers] Re: Activity Lifecycle Documentation Question
Yes! Having mostly lurked over this list for the last year and half, I see this thread come-up too frequently, and this area caused me a lot of confusion. I don't want to change the thread, but want to emphasize that to make intelligent suggestions, one has to understand the process. These questions actually seem to arise more from people with a lot of experience to other programming environments and lacking in Java depth rather than plain beginners and I think it is because developers are fearful of making assumptions to fill in documentation holes/conflicts because they KNOW that is where things can will break. The whole scenario was even muddier for me because I had constant questions in my mind as to the relationship of things like Java static initializers to these life-cycle Objects (I knew neither the framework (or similar frameworks and was new to Java (still feel like a newbie)) - for instance when the process is killed but the system decides to keep the Activitiy around, does the framework re-do static initialization of the Objects if it re-uses the killed activity? Since the document doesn't say, the developer has to black-box, then if the framework is every changed, unless you programmed defensively (assume statics are not repeated) your application may break. Clearer documentation would help a little (for those that read it :-), saving Dianne, Mark, and all the rest of you very generous contributors (thank you!) time for other replies. I can rock with documentation issues in most areas (I can always go peek at the source), but activity life-cycle is the back-bone of every application design; it deserves to be held to a higher standard, and end-consumer developers need a high degree of confidence that the process is accurately documented without having to look at the source -- to me, the documentation should be a contract between the framework developers and the framework users (programmatically)... thanks for all the replies and the people that are persistent in their pursuit of definitive answers. On Apr 28, 1:50 pm, Indicator Veritatis mej1...@yahoo.com wrote: Eric is not the first to observe that the documentation on these topics is too confusing. But where should he make this 'contribution' you suggest? Is the documentation somewhere under the Android Open Source project athttp://source.android.com/? On Apr 27, 10:23 pm, Dianne Hackborn hack...@android.com wrote: Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If
[android-developers] Google Market cancelling orders
All of a sudden, since the Market underwent it's recent multiple country expansion, I'm seeing, on a fairly regular basis, cancellations with a subject: Order XYZZY has been cancelled by Google With an explanation that boils down to: ...because we were unable to verify that buyer's account information... So far it's all been with customers' billing addresses in S. Korea? Wondering if any other developers with paid apps are seeing an increase in these types of cancellations and if they are clustered to any particular country? -- 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
