Lines Matching full:possible
27 <li> <a href="#Possible_scope_for_Cupcake">Possible scope for Cupcake</a>
174 <b>ALSO</b> See also <a href="#Future_Directions">future directions</a> for possible additional technical changes.
176 <h3><a name="Possible_scope_for_Cupcake"> </a> Possible scope for Cupcake </h3>
186 and therefore reducing the number of classes when possible or relevant can reduce the memory
278 It'd be good if the download manager could be built against the SDK as much as possible.
480 The various constants that are meant to be used by applications are all defined in the <code>android.provider.Downloads</code> class. Whenever possible, the constants should be used instead of the explicit values.
522 <tr><td > <code>Downloads.STATUS</code> </td><td > <code>"status"</code> </td><td > Integer </td><td > Read </td><td > </td><td > See <a href="#StatusValues">Status codes</a> for details of possible values. </td></tr>
532 <tr><td > <code>Downloads.OTHER_UID</code> </td><td > <code>"otheruid"</code> </td><td > Integer </td><td > Init </td><td > </td><td > Requires the <code>android.permission.ACCESS_DOWNLOAD_MANAGER_ADVANCED</code> permission. Used to be readable and writable. Might disappear entirely if possible. </td></tr>
655 Unfortunately, that's not always entirely possible.
683 <li> I intend to renumber the error codes, especially those in the 4xx range, and especially those below 490 (which overlap with standard HTTP error codes but will probably be separated). Reflection would improve the probability to getting to them in the future. Unfortunately, the names of the constants are likely to change in the process, in order to disambiguate codes coming from HTTP from those generated locally. I might try to stick to the following pattern: where a constant is currently named STATUS_XXX, its locally-generated version in the future might be named STATUS_LOCAL_XXX while the current constant name might disappear. Using reflection to try to get to the possible new name instead of using the old name might improve the probability of compatibility in the future. That being said, it is critically important to properly handle the full ranges or error codes, especially the 4xx range, as "expected" errors, and it is far preferable to not try to distinguish between those codes at all: use the functions Downloads.isError and Downloads.isClientError to easily recognize those entire ranges. In order of probability, the 1xx range is the second most likely to be affected.
862 <li> Provider should return more errors and throw fewer exceptions if possible.
1007 <li> Turn on wifi if possible
1059 <li> <em>[DownloadProvider.java]</em> It's possible that the last update time should be updated by the Sevice logic, not by the content provider.
1087 <li> Should keep a bit of "emergency" database storage to initiate the download of an OTA update, in a file that is pre-allocated whenever possible (how to know it's an OTA update?).
