List views need to have their header view set _before_ an adapter is
assigned to them.
Was incorrectly passing an application context instead of an Activity
context to the progress dialog for swap.
Extend ActionBarActivity rather than FragmentActivity.
Don't persist swap workflow state to disk, only store it in the
singleton.
All the code from the activity and the fragments has been successfully
ported to the SwapWorkflowActivity + Views. Thus, the code is no longer
useful, as it was only kept over the previous WIP commits so that it
can be referred to to help re-implement fragments with views.
Currently the view to show after pressing the back button is defined
by individual InnerView classes. For example, the JoinWifiView always
says its previous step is the SelectAppsView. This works for the most
part, but doesn't work for:
* The first StartSwapView class (instead handled by a special case in
the Activity).
* WifiQrView which could either be going back to the NfcView or the
JoinWifiView, depending on a few cases, which the WifiQrView probably
shouldn't care about.
The state is saved to a preference file, but that is abstracted from
the SwapWorkflowActivity. It interacts with a SwapState object, which
is relatively safe in that you should not be able to save it into an
invalid state.
Note: At this point it is not tied to any service. I'm not sure it will
ever have to be either, as the service needs to persist state somewhere
anyway, so that will probably also end up saving to a preferences file
too.
As per the select apps list, there is quite a bit of business logic
in this class, which is now spread between the activity and the view.
The activity needs to handle some stuff, because the zxing library
routes intents to either an activity or a fragment.
There is quite a lot of business logic that was moved directly from
the fragment to the view. Before this feature is complete, that logic
should either be moved into the activity, or into some sort of
associated Presenter class for the JoinWifiView.
Not worrying about styling yet, just functionality. Added an InnerView
interface that these views can implement. Currently it asks them to
populate the menu. It may be slightly inefficient if we end up with a
popup menu, because it is called onPrepareOptionsMenu, but expects the
inner view to inflate the menu. However, for swap this shouldn't be an
issue, as all the menus pretty much fit in the action bar of most screen
sizes.
Added a SwapWorkflowActivity to re-implement the SwapActivity.
Once all the fragments have been refactored into views, then the
SwapActivity will be removed.
The multiple occurances of "if (Build.SDK_INT < ... )" statements
hint at the prospect that there are a couple of different implementations
of this class which behave differently. The new classes start with
InstallFDroidAsSystem, and then there are SDK specific subclasses
which provide the customization relevant for those subclasses.
The NFC message now is handled by the FDroid activity, so it is treated
the same way as every other incoming repo URL. Because FDroid handles
incoming intents correctly, the NFC one just magically works when
the <intent-filter> is moved from ManageReposAcivity to FDroid without
further code changes.
The other change is that the two way swap only happens when both are
actually swapping. Otherwise, we will send a request for someone to
swap with us, when we are incapable of swapping with them.
Fixes#267.
Pretends that the swap repo never existed, by deleting it before adding
the new repo, and showing the same message that is shown when a new
repo is added. This does not change behaviour for existing non-swap
repos. They are not deleted before being added again, or else we would
lose the ability to verify the fingerprint of an existing repo is the
same as a newly added one with the same URL.
Note that this has the effect that the fingerprint/pubkey of the swap
repo is nuked when adding that repo manually.
Internationalised the string "BAD FINGERPRINT" while I was at it.
Force entire swap process to be portrait.
Although this is usually regarded as poor form, it is currently better
than the alternative which is the whole swap process poohing itself
when a device is rotated. In the future, it may be worthwhile investing
in designing a proper UX for landscape swap too. However the process
of swapping can be quite complex if not presented well, and so it might
end up being too much work to maintain two different UXes for landscape
and portrait.
See merge request !89
Although this is usually regarded as poor form, it is currently better
than the alternative which is the whole swap process poohing itself
when a device is rotated. In the future, it may be worthwhile investing
in designing a proper UX for landscape swap too. However the process
of swapping can be quite complex if not presented well, and so it might
end up being too much work to maintain two different UXes for landscape
and portrait.
The code for promoting an untrusted repo with no fingerprint, to
a repo with a pubkey and a fingerprint, was still there. The problem
was that it was being executed after we verified the index.jar cert
against the pubkey stored against the repo (which is empty for TOFU
repos).
This change makes it so that if we are updating a repo without a
fingerprint, then it is a TOFU request, and we don't try to verify
the certificates.
closes#85https://gitlab.com/fdroid/fdroidclient/merge_requests/85closes#254https://gitlab.com/fdroid/fdroidclient/issues/254
