Age | Commit message (Collapse) | Author |
|
I've added "from providerlistfragment" just in case there is any other "top padding" string suitable in other class in the future.
I've removed the auxiliar variable in the block of code from ProviderListFragment, there is no need of if now we have a constant in that class.
|
|
|
|
|
|
|
|
|
|
|
|
into develop
Conflicts:
src/se/leap/bitmaskclient/Dashboard.java
|
|
Conflicts:
src/se/leap/bitmaskclient/ProviderAPI.java
res/values/strings.xml (Re-add lines removed in 7297632a01d5fb606b901d8c54e190e28b95716e )
|
|
Log window Activity is gone with ics-openvpn purge.
We will want it back, but we will bring back only what's needed.
|
|
This classes were an obvious choice, there may be more unused classes
around there.
Conflicts:
src/se/leap/bitmaskclient/ProviderListFragment.java
|
|
This means we obtain the SharedPreferences object each time we want to
use it. This yields to longer code lines while reading and writing to
them.
|
|
|
|
|
|
Conflicts:
src/se/leap/bitmaskclient/ConfigurationWizard.java
src/se/leap/bitmaskclient/Dashboard.java
src/se/leap/bitmaskclient/ProviderAPI.java
src/se/leap/bitmaskclient/ProviderListFragment.java
|
|
|
|
|
|
|
|
I've also removed some spaces from the text.
|
|
|
|
|
|
|
|
|
|
It also (supposedly, I didn't test because Bitmask is working ok from our client point of view) distinguishes between cancelling a new custom provider and cancelling a preseeded provider.
|
|
The user can change the new provider's data entered before failing.
|
|
|
|
|
|
|
|
Next step: remove the provider from the list (big security hole, since all providers present on the list are assumed to be secure).
|
|
|
|
ProviderAPI has now 3 different static variables, each one for the 3 files that have to be downloaded to set up a provider.
|
|
|
|
I/O error at login phase fixed.
|
|
Setting up a provider makes the progressbar move according to the number of files downloaded (1/3, 2/3, 3/3).
Next step: recover from download errors individually. That means that if a download fails but the others went OK, the user will be prompted to retry that individual failing download.
|
|
|
|
This method uses another 3 to download each file.
Next step: broadcast progress and remove unnecessary methods.
|
|
|
|
Adding a new provider is the same that selecting a new one, using the same methods and following the same workflow.
|
|
I've refactored everything to be able to remove all but provider.json
url at urls files.
|
|
I'm targeting to refactor the whole ProviderItem class because I've not
used the Provider class so far and I should not duplicate information
from "Provider" into "ProviderItem".
|
|
There was a nullpointer already fixed in another branch which
completely complements this one. The message shown to the user is empty,
but that belongs to bug/more-detailed-response-to-CW-errors.
|
|
|
|
|
|
I/O error at login phase fixed.
|
|
Setting up a provider makes the progressbar move according to the number of files downloaded (1/3, 2/3, 3/3).
Next step: recover from download errors individually. That means that if a download fails but the others went OK, the user will be prompted to retry that individual failing download.
|
|
|
|
This method uses another 3 to download each file.
Next step: broadcast progress and remove unnecessary methods.
|
|
|
|
Adding a new provider is the same that selecting a new one, using the same methods and following the same workflow.
|
|
I've refactored everything to be able to remove all but provider.json
url at urls files.
|
|
I'm targeting to refactor the whole ProviderItem class because I've not
used the Provider class so far and I should not duplicate information
from "Provider" into "ProviderItem".
|