Back in my C64 days, I remember that the best protections (DRM)
involved very subtle behavior changes.  The app simply crashing were
the easy ones to remove.  But when you had enemies not appearing, or
the collision detection going wonky, those could be tough.

What I am trying to say is, if you are going to do to DRM, make it as
subtle as possible.  Let's take TreKing's Chicago public transport
app.  If it gave the user the wrong arrival info, they might be more
screwed than if it just stopped working altogether.



On Nov 11, 10:56 am, Nikolay Elenkov <nikolay.elen...@gmail.com>
wrote:
> On Fri, Nov 11, 2011 at 11:45 AM, Chad Ata <chad...@gmail.com> wrote:
> > Thanks for the response Nikolay,
>
> > I was hoping to avoid server-side checks because I don't want potential lag
> > or bugs to affect the legit users. But I'll consider your suggestion if this
> > becomes a big problem for us.
>
> You could embed the hash as a resource with a non-obvious name,
> and tripple-base64 encode it for extra fun if you don't want to use a
> server. If they are changing/modifying your resources, it might be
> better to store bits of it in code and calculate it dynamically
> though.

-- 
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

Reply via email to