Thanks, I followed up on that idea by creating a placeholder
interface; I am limiting this to the problem of WebView callbacks so I
call it "JavascriptCallback".
If I follow the convention of implementing this interface wherever
appropriate, the following Proguard rules work:
---------------------
-keep public class * implements com.trans_code.android.JavascriptCallback
-keepclassmembers class * implements JavascriptCallback {
void on*(***)
}
---------------------
My Proguard knowledge is basic but this seems to be enough for the use
cases I can think of, where a convention is assumed that callback
methods will start with "on".
I wonder if this placeholder interface or something similar should be
in the framework as a general purpose tag for RPC-type callbacks to
Java that should not be renamed by an obfuscator.
--SJ
On Sun, Nov 7, 2010 at 6:35 PM, Daniel Drozdzewski
<daniel.drozdzew...@gmail.com> wrote:
> On Sun, Nov 7, 2010 at 10:41 PM, Stephen Jungels <sjung...@gmail.com> wrote:
>> I've recently started using the WebView Android / Javascript interface
>> in my projects (and I think it's pretty cool; article here:
>> http://developer.android.com/resources/articles/using-webviews.html).
>>
>> The problem is that when obfuscation is turned on, the callbacks from
>> Javascript to my Android code no longer complete, because the language
>> binding is unaware of the renaming performed by Proguard.
>>
>> I can fix this on a case-by case basis; for example in the very simple
>> code I am using now, the following additional Proguard rules are
>> enough:
>>
>> -----------------------
>> -keep public class com.trans_code.android.JsCallback
>> -keepclassmembers class * {
>> public void doneClicked();
>> }
>> ----------------------
>>
>> However the second rule seems too broad, and both rules are unique to
>> each project that uses the Javascript callback.
>>
>> Any guidance on how a better rule can be written that catches every
>> use of Android - Javascript bindings, and nothing else?
>>
>> Thanks,
>>
>> SJ
>>
>
> Stephen,
>
> I am not sure, whether you would be more selective with not
> obfuscating some classes, but you could do the following:
>
> - define a placeholder interface called say NonObfuscateable (I know
> it sounds dreadful, but you get the gist)
> - make all classes that you want to keep implement this interface
> - tell Proguard to keep the classes that implemented your interface
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To 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
