This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Add @WakeLock(WakeLockLevel) annotation for a method #863
Description
You can get the WakeLock with something like this:
@SystemService
PowerManager powerManager;
public void foo()
{
PowerManager.WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, TAG);
wakeLock.acquire();
doSomething();
wakeLock.release();
}But it would be very helpfull and clean when you can do something like:
@WakeLock(level = WakeLockLevel.PARTIAL_WAKE_LOCK)
public void foo()
{
doSomething();
}Which will wrap the wakeLock acquire and release around the method. Like the @UiThread or @Background annotation.
Activity
DayS commentedon Jan 6, 2014
Good idea. But the cleanest code would be like this :
Bendr0id commentedon Jan 6, 2014
Sure. Was just a quick sample.
dodgex commentedon Sep 2, 2014
I have implemented this feature.
as i have to do some cleanups before proposing a PR i'll first give a short info about what i've done.
the syntax is like @DayS suggested. beside
levelthare is a valuetagand oneflagstagdefaults to"NO_TAG"and that results in the simple name of the enclosing element (enhanced class)leveldefaults toPARTIAL_WAKE_LOCKflagsdefaults to{}aka no flagsalso
@WakeLockplays well with@Backgroundand@UiHandleras the wakelock is taken inside of the Runnable/Task.As any application using a WakeLock must request the
android.permission.WAKE_LOCKpermission, i added the permission check to validation.at the moment there is just one known issue with
@WakeLockand@Traceif the method has a return value. in that case@Traceswallows the wakelock acquisition as it trys to store the return value but only calls the super method then. I'm not sure how to handle this. At the moment i see thre ways. The easy (and somehow dirty) way to add a warning if@Traceand@WakeLockwhere used on a method with a return type. The easy (and cleaner but more restrictive) way to not allow return values for@WakeLock. or the hard (if not impossible?!) way of changing@Tracebehaviour for return values. while i have a potential (and possibly even easy) solution for the hard way, i think it would be VERY ugly... (wrapping the original method body in an annonymous class).WonderCsabo commentedon Sep 2, 2014
Great job! I love the validation, but what about library projects? They can use the WakeLock code without any permissions in the manifest, since the app can declare those. But it can be also a good idea to declare the permission at the library level, so it get picked up in the app after manifest merging, also the user of the library can see what permissions the lib needs. To be honest i only developed a library project once, so i do not know the practices here, but i would vote to declare the permission at the library level (so your validation is OK).
About the issue: since
@Traceis just a debug annotation, and it is even disabled by default, i think we can even go the dirty way. I do not like the easy way, since that limits the usage of the annotation because of@Trace, but the user may not employ@Traceat all. About the hard way: Creating an anonymous class for this is really not nice.Either way, roll out a PR, we should discuss implementation detail there. Also @yDelouis WDYT about this?
dodgex commentedon Sep 2, 2014
As mentioned i want to clean up the Code first before i create a PR. I think tomorrow evening i'll get it done.
I implemented the validation the same way like the
hasInternetPermission. Actually i refactored it a little bit (you'll see that tomorrow). So for library projects the permission validation is off.Ok. So i'll add a warning if
@Traceis present and the method returns something.WonderCsabo commentedon Sep 2, 2014
OK, i see now, we do not check against lib project permissions. Shoot, i should better know our codebase... I look forward to the PR.
dodgex commentedon Sep 3, 2014
@WonderCsabo i thought about the permission validation on library projects.
maybe it is a good idea to add a warning for required permissions if an annotation with permission requirement is used in a library project. so that the library developer is aware of the fact that there is a permission that might be required. this way he can decide if he adds the permission to its own manifest (eg. if the annotated method is a core function that is most likely to be called) or if he only notifies the user in his docs/readme (eg. for methods that could be used but not in all use-cases)
i think simply ignoring the fact that there is a required permission is the wrong way.
WonderCsabo commentedon Sep 3, 2014
I agree with you, as i have written in my older comment. @yDelouis ?
dodgex commentedon Sep 3, 2014
Note to self: test how
@Clickand other listeners works together with this annotations. not sure how those call the method.WonderCsabo commentedon Sep 3, 2014
Listener annotations do not override the method, just call them, so they should just work fine.
Bendr0id commentedon Sep 3, 2014
@dodgex Great job! Thanks for that!
WonderCsabo commentedon Sep 20, 2014
Implemented.