Dan Galpin and Trevor Johns gave an excellent talk at Google I/O this year
exactly on this topic. They go over various methods of obfuscation as well
as license validation and other valuable tools. If you're not distributing
through Market, some of it won't apply to you (since you can't use
I'm working on creating a swipe-to-dismiss list view adapter. My basic
methodology is to wrap the list item's view as the second view in a
ViewPager and provide the necessary callbacks in the item change listener
of the ViewPager. Through much pain I've got the View recycler working as
In the case of a kiosk app you'd need to build it into the ROM. Since
the honeycomb source hasn't been released you'll have a hard time with
that. Looks like your best bet would be to base it on a 2.3 ROM and
have the app work for xlarge screens. That means porting 2.3
yourself, most likely.
I forget who it was specifically that had said it, but the Android
team in general does not like OS level gestures. They limit what
applications are able to do. I tend to agree with them.
On Jul 28, 7:38 pm, bmjg b...@home.nl wrote:
Maybe the status bar should optionally be able to hide
Use the in-app billing model. It will save you a lot of headaches.
To solve the issue I raised earlier, you could turn the current paid
app into more of a License key package. On first run your freemium
app would check for the presence of the paid apk and ask the Market to
replay your managed
Honestly, you'll probably do better to have a single .apk and use an
in-app purchase to do the free to paid conversion. There was another
thread on here that discussed this extensively.
On Jul 24, 2:34 am, Davy ddewa...@gmail.com wrote:
Hi,
I'm thinking about offering a free / paid version of
The only problem I could forsee is the stuff that would normally be
handled as a managed purchase. Namely: the reinstall issue.
Scenario: purchased old version, uninstalls app, downloads new
version. In this case the app should be installed with the unlock
complete, but it won't be without some
You might also look into using a ViewFlipper. Trades a bit of memory
in exchange for speed. Fragments may be of use too. This is one of
those problems that has many solutions and finding the best one
depends on the specifics of your app.
On Jul 22, 9:04 pm, TreKing treking...@gmail.com wrote:
I recently finished a project where we used an in-app purchase to do
the transition. Made it nice for the coders since we only had one
code base (in this case we had a separate apk for an HD version with
different levels, so it took it from 5 projects down to 3: sd, hd, and
core with no need for
/res/drawable-xlarge
On Jul 15, 8:27 pm, Alec B. Plumb abp...@gmail.com wrote:
With 3.2, honeycomb devices now have the option to have an application
Stretch to fill screen. In my opinion, my apps look better in this
mode than in the regular zoom mode. I know all about Fragments and how
I
It very heavily depends on the kind of app. I'm nearing the end of a
project porting a 2d game over and it's been rough. It took me a week
and a half translating line by line several thousand lines before I
had something I could even attempt to run. That's because none of it
was using the
It seems the Market would benefit greatly and would be much easier to
navigate if it was aware of theme/plugin applications in a
hierarchical manner. For example: suppose I wanted to install
ADW.Launcher. Doing a search in market, it is unclear which is the
ADW.Launcher app, and which are simply
Chalk one up to the Law of Leaky Abstractions?
On Apr 30, 9:19 pm, Eric e...@alum.mit.edu wrote:
On May 1, 12:01 am, Romain Guy romain...@android.com wrote:
If you are doing *very* frequent updates (several times per second for
instance, with let's say a progress bar or some sort of
Even if there is a high enough data rate, I think transmission
distance would be an issue. Most bluetooth devices are only designed
for a range of about 10 meters, and less if there are walls and other
objects to go through. It seems to me that establishing a sort of ad-
hoc wifi network would
Does anyone know of a good way to create an AdapterView that will
sequentially place children horizontally until that line becomes full
and will wrap down to the next line (similar to word wrapping, but
with whole views). I'm in a situation where I don't know at runtime
how wide my AdapterView
Disregard. I think GridView will do exactly what I need it to do.
On Feb 17, 4:15 pm, keyboardr keyboa...@gmail.com wrote:
Does anyone know of a good way to create an AdapterView that will
sequentially place children horizontally until that line becomes full
and will wrap down to the next
I'm trying to figure out a way for my AppWidget's onUpdate to be
triggered by a change in ActivityManager.getRecentTasks(). Right now
it's just working off AlarmManager and updating every time (regardless
of whether there were any changes), but going off ActivityManager
seems like it would
Caribbean accentWelcome to Android. This is Android. Welcome. You
can do anything with Android. Anything at all. The only limit... is
yourself. Welcome to Android. WELCOME... TO ANDROID. Yes... this is
Android. And welcome to you who has come to Android. Anything is
possible with Android.
I usually use a wrapper class. Just create a custom
NonConfigurationInstance class that has your object array as one of
its member variables.
On Jan 26, 5:27 pm, som som.mukhopadh...@googlemail.com wrote:
Hi Guys,
I have developed a Paint application on Android. I have reached a
stumbling
, 3:07 am, Kostya Vasilyev kmans...@gmail.com wrote:
I believe minWidth comes from the widget_info.xml in your package, so it's
not very useful to the widget's own code.
As for different widget sizes with different displays and launchers -
*sigh*.
2011/1/17 keyboardr keyboa...@gmail.com
Does anyone know how to allow your appwidget to account for being
resized (a la LauncherPro or ADW)? My widget already dynamically
figures out how many of an item to draw based on the size of the
widget (meaning I can have multiple providerInfos without having to
change the provider), but
I know Nintendo originally tried to use accelerometers to figure out
where it was pointing, and while that's theoretically possible, in
practice the accuracy just isn't good enough. The acceleration most
of the time is small enough that even the slightest error will throw
the whole calculation
You could also try integrating the readings from the accelerometers,
but I suspect this would give you even worse accuracy and you'd have
to have some way to calibrate the zero point.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post
I'm not 100% familiar with this aspect of the G1, but I know Nintendo
had a similar problem with their Wiimotes. That's why they have the
sensor bar set up: they couldn't get their accelerometers to be
accurate enough to track position.
On Jul 9, 2:23 pm, dilit dmit.lit...@gmail.com wrote:
24 matches
Mail list logo
