Inconsistent formatting types for argument #1 in format string
searchres_napps ('%s'): Found both 'd' and 's' (in values/strings.xml)
This lint check ensures the following: (1) If there are multiple
translations of the format string, then all translations use the same type
for the same numbered arguments (2) The usage of the format string in Java
consistent with the format string, meaning that the parameter types passed
to String.format matches those in the format string.
<string name="searchres_napps">Sa gasit o aplicatie potrivita cu %s\'</string>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The update notification was not taking ignored apps into account.
This is the first manifestation of a class of bug I feared whereby
the properties of an App object are not initialized, but no error
is thrown. It occured because we were iterating over apps that were
created from the index file, rather than our database. Hence, they
had no knowledge about whether they should be ignored or not.
Also took the chance to perform a minor refactor of UpdateService
class. The onHandleIntent method was getting huge, so I extracted
two methods: verifyIsTimeForScheduledRun() and
performUpdateNotification(), as well as removing the unused "success"
flag.
The two methods should theoretically make the class more testable
later, as we can test the scheduled run code, and the update notification
code in separate tests, but we'll wait and see if that eventuates.
Not sure that the "parent" activity of ManageRepos is required in
the manifest any more, due to the fact that the main use seems
to be to direct the "NavUtils.navigateUpSameTask" method uses it,
but this change switches to "NavUtils.navigateUpTo" and specifies
the activity explicitly.
In order to support suggested version, I didn't want to have both
suggested version + versionCode in the App table. Rather, just the
code, and then use that (and the apps id) to join onto the apk table.
This is something we wanted to do elsewhere, so I refactored the
QueryBuilder class from the ApkProvider so that it can also be used
by the AppProvider.
This is just a cosmetic fix to make the RTL layout look like the normal LTR
one. It is, effectively, making non-RTL text be aligned to the right. I
suppose that's fine, for the sake of making it readable since we don't want it
aligned to the left, breaking the layout.
Following the Android 4.2 changes, which explain how to add native support for
RTL, I've replaced Right for End and Left for Start. Enabling RTL to see the
results.
Following the Android 4.2 changes, which explain how to add native support for
RTL, I've replaced Right for End and Left for Start. Enabling RTL to see the
results.
Removed unused code from ApkProvider.Helper, made it throw proper
exceptions when trying unsupported operations. Refactored tests
a little bit to facilitate separate test cases for the provider
and its helper.
The bug is explained in detail in the issue tracker.
This change added guard condition to check for existence of the field
before adding.
While I was at it, I also guarded a bunch of other ALTER statements
with the if (!columnExists()) check. It turns out that many of them
break, but we only saw the first one because it threw an exception
before getting to the others.
This marks a method as overriding another method, and makes sure that it
matches the signature of the method it is supposed to be overriding,
otherwise it gives a warning.
Its a bit verbose, but can catch mistakes and save time. And the default
Android profile for Eclipse always adds them automatically...
