Flowlie

flowlie

NOTE: I’ve deprecated Flowless (and have abandoned using Flow) in favor of what I wrote based on that from scratch: Simple-Stack . So you should keep in mind that I am no longer using this, because Simple-Stack solves quirks that I didn’t like about Flow’s design. — — — — — — — — — — — — — — — — — — — — — — — — — This is a follow-up article to . Saying No To Fragments and Activities: Creating View-driven Applications with Flow While I claimed that that article will get to the point, it was more-so a comparison of how things are lately with (and ), . So one could argue that it did not get straight to the point, after all. Flow 1.0-alpha2 Flowless versus how things used to be with Flow 0.8 So let’s get to it, shall we? Flow: a backstack manager As , the primary task of Flow (and the instance itself) is to manage the . All it really cares about is the (essentially a ), and exposes operators that allow it. stated in a previous article Flow backstack History List<Object> manipulating Keys: representation of application state The primary difference using Flow compared to just Activities is that instead of having an , you have a History of “key” objects that are just general Parcelable objects with and that represent what view you’re supposed to be showing. implicit backstack created by a series of Intents that open a bunch of Activities hashCode() equals() (In fact, it doesn’t have to be a view, if you’re a heretic, you can even use Fragments with it. No, really; just use the newly added _FragmentManager.commitNow()_ , and don’t use _addToBackStack()_ , defer backstack manipulation to Flow instead. Theoretically, it should work, although I must admit I haven’t tried it yet.) A possible example key would be the following: But if you don’t like extracting values from annotations, then you can just use interfaces and method calls. It’s up to you! This allows simple initialization for what your application state should be. And it also allows you to easily set whatever view you want to test with instrumentation tests. You might be thinking, “wait, but this is a whole bunch of methods in the key, I thought this was going to make my life simpler?!” Actually, it does. Exactly because this kind of “behavior” that is encoded here in the key used to be thrown randomly into Fragments, that were manipulating the Toolbar title in the Activity directly. Here this is something you can globally do in your dispatcher implementation, and it’s set properly on back press too with minimal effort (in fact, it works out of the box). Custom Views, and listening to the lifecycle This is a -specific feature, partly piggybacking on top of the fragment in the original Flow. Flowless InternalLifecycleIntegration You generally need to know when your View is ready and its state is restored. You must also know when your View is killed, so that you can unsubscribe your subscriptions, or unregister from event buses. Previous Flow examples used to show and as the callbacks to be used, but that is actually unreliable. There are cases when is called, but is not. In that case, you do not receive any callback to , which means that you can lose your state! onAttachedToWindow onDetachedFromWindow onFinishInflate() onAttachedToWindow() onDetachedFromWindow() If you’re curious, this is most likely why the library exists. square/coordinators Instead, Flowless introduces the interface, which if you implement, then provides you the callbacks: and . FlowLifecycles.ViewLifecycleListener onViewRestored() onViewDestroyed() Additional lifecycle callbacks In other cases such as writing a , you might need to listen to permission results, or activity results. CameraView For and , you need to delegate these callbacks to the Dispatcher manually. onActivityResult onPermissionResult A possible base activity that hides this from you would be the following: Once the permission result delegation is added, the dispatcher forwards this event to the current active view. This way, you can handle any lifecycle event callback you need in your view. ServiceProvider: sharing services across the view hierarchy This is a new class in Flowless, its counterpart used to be .with its corresponding . The is pretty much just a that is stored inside Flow’s to preserve them across configuration change, very similar to Mortar which is essentially a . The initial key in this case of course is the itself, and not a “scope name” specified as a String. Flow.Services ServiceFactory ServiceProvider Map<Object, Map<String, Object>> InternalLifecycleIntegration Map<String, Map<String, Object>> Key The difference is that in the original Flow 1.0-alpha2, the were managed internally based on a reference count, based on interfaces such as or . This could cause problems even if you weren’t using it, which is what caused the crash that made me fork Flow and create Flowless in the first place. Flow.Services TreeKey MultiKey Instead, in Flowless, the expects you to set it up in the Dispatcher however you see fit. ServiceProvider Through , the allows you to obtain any service from your context, just like you can obtain Flow via . the magic of redefining [getSystemService()](https://github.com/Zhuinden/realm-book-example/commit/619546401dcade1fbc02001e8b12d71bfcec2952) ServiceProvider Flow.get(context) Sharing a Dagger2 component In the MVP example, this is how scoped components are provided down the view hierarchy. This allows us to obtain the Dagger2 component from any context — primarily within views of the custom view’s view hierarchy. Dispatcher: which determines what happens on state change The last and most important component of a Flow-based application is its Dispatcher implementation. This is what globally handles what should happen when you go from Key A to Key B. The most typical implementation would persist the state of the previous view, inflate the new view, restore state to the new view, remove the previous view, add the new view, and callback to signal completion. The following example also adds the Dagger2 component by and associate it with the given key, making the component accessible within the view hierarchy. DaggerService.TAG In the middle, you can see the Service being set up for the current key: the Dagger2 Component. This is basically where the “magic” happens. In this case, it’s 60 lines with comments, compared to the FragmentManager that is 2000 lines. I guess there’s a win there in simplicity. Conclusion Hopefully this helped understand how to use , and how to create a simple MVP-based (or maybe even MVVM-based with Data-Binding or RxJava!) application without using fragments or any kind of additional “arcane folklore” beyond an explicit backstack. Flowless The app is driven with just simple parcelable POJOs, and you write how to switch between the states only once. Simpler than either s or s. FragmentTransaction Intent The example cited multiple times during this article is available . Flow is primarily responsible for the way the layer works. here presentation

Simpler Android apps with Flowless 1.0-RC2 (or Flow 1.0-alpha2)

UNITED STATES OF AMERICA v. SAMUEL BANKMAN-FRIED Court Filing Lewis A. Kaplan, December 9, 2022 is part of . You can jump to any part in this filing . This is part 11 of 25. HackerNoon’s Legal PDF Series here STATEMENT OF FACTS II. The Bahamas Extradites Mr. Bankman-Fried Pursuant to Simplified Extradition Proceedings. A. Mr. Bankman-Fried Consents to Simplified Extradition After Considering the Charges in the Diplomatic Note and the Rule of Specialty. Mr. Bankman-Fried was subsequently extradited to the United States based on the first seven counts stated in the Diplomatic Note (corresponding to Counts 1-7 of the Original Indictment). On December 13, 2022, formal extradition proceedings were commenced in Magistrates’ Court in the Bahamas. See Ex. 1 ¶ 2. On December 20, 2022, Mr. Bankman-Fried consented to extradition pursuant to the simplified procedures set forth in Article 15 of the Extradition Treaty and Section 17 of the Bahamas Extradition Act. See Ex. 1 ¶¶ 3-4; Ex. 2 (Warrant of Surrender attaching Extradition Treaty Between the Government of the United States of America and the Government of the Commonwealth of the Bahamas, Bah.-U.S., Mar. 9, 1990, S. Treaty Doc. No. 102-17) at SDNY_03_01098076; Ex. 3 (Bahamas Extradition Act) 12 § 17; Declaration of Honourable James Lewis KC, May 8, 2023 (“Lewis Decl.”) ¶¶ 4, 13, 28, 31, 33, 66. [12] As set forth in his written consent, Mr. Bankman-Fried consented to simplified extradition after considering the description of the charges set out in the Diplomatic Note and the SDNY Arrest Warrant, the rule of specialty as incorporated into the Extradition Treaty, his desire to be released from custody in order to assist in efforts to make FTX customers whole, his right to formal extradition proceedings, and his right to be extradited without formal extradition proceedings. Ex. 1 ¶ 3. The rule of specialty is reflected in Article 14 of the Extradition Treaty, which provides: A person extradited under this Treaty may only be detained, tried, or punished in the Requesting State for the offense for which extradition was granted, or – . . . any offense in response of which the executive authority of the Requested State, in accordance with its laws, has consented to the person’s detention, trial, or punishment; and for the purposes of this subparagraph the Requested State shall require compliance with the extradition procedures specified in Article 8 and the submission of the documents specified in that Article. Ex. 2 at SDNY_03_01098074 to -8075. Article 14’s requirement that the requested state’s consent must be given “in accordance with its law” incorporates the “dual criminality requirement,” which, as discussed below, provides that the requested state may only consent to the prosecution of the defendant for conduct that is considered criminal under its laws. Mr. Bankman-Fried’s written consent did not in any way suggest that Mr. Bankman-Fried waived the protection of the rule of specialty or dual criminality; to the contrary, it indicated that he intended to preserve his rights thereunder. [12] Courts may consider expert testimony in considering a defendant’s specialty challenge. See United States v. Fowlie, 24 F.3d 1059, 1064 (9th Cir. 1994) (district and circuit courts considered testimony of defendant’s expert witness on Mexican law in deciding defendant’s rule of specialty objection). Thus, accompanying this Memorandum of Law is the declaration of James Lewis KC, an U.K.-based barrister who is an expert in international and Bahamian extradition law, having appeared in extradition matters in Bahamian courts at all levels. See Lewis Decl. ¶¶ 5-6. Continue Reading . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case S5 22 Cr. 673 (LAK) retrieved on September 1, 2023, from is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. Storage.Courtlistener

Sam Bankman-Fried Only Agreed to a Simplified Extradition Based on 7 of the 8 Charges Against Him

If you’re a developer working on a web3 app, you know that onboarding mainstream users into web3 is difficult. Even with the promise of truly owning your data, making near-free worldwide payments, and using a censorship-free system, the current process of creating and using a digital wallet is just too hard. Fortunately, there’s a better way. promises to streamline the process, making user onboarding seamless and simple. —a decentralized, public, layer-one blockchain designed for building web3 experiences for mainstream users—has used account abstraction to combine a model with to create an onboarding that is easy, simple, and as straightforward as traditional apps. Account abstraction Flow hybrid custody walletless onboarding Let's dive into the details to see how Hybrid Custody and Walletless Onboarding work together: the architecture, the code, and what we can expect moving forward. Why web3 onboarding is so difficult Digital wallets bring all the benefits of web3, including the assurance that no one can control your assets. There are no middlemen such as banks taking a percentage of your money, or third parties dictating what you can do. However, because most wallets are “self custody” (meaning only you have access), you—and only you—are in charge of your keys. There is no customer support if you make a mistake. This means you must store your keys safely. Don’t store them in clear text on your computer where they can be hacked. And don’t write them down where someone can read them. And don’t lose them, because there is no reset password in web3, so you’ll lose . You can see the issues. everything In addition to the challenges of self custody, you also need to understand tokens and payments. How do you pay for your transactions? What tokens do you need? How do you move from fiat to tokens? How do you transfer the tokens once you have them? Oh, you made a typo when you sent your tokens? Sorry, they’re lost forever. Again, you can see how difficult this all is. With all these obstacles, it’s easy to see why many people don’t make it past step one of signing up for your app. Custodial wallets: great UX, lacking ownership Developers tried to solve this issue with . These wallets manage the keys for you and have many benefits. custodial wallets Signing up is easy. You can use an email and password, as you would for a traditional service, and the wallet provider takes care of the rest. If you lose your login credentials, your keys are still accessible on the provider's servers – you can simply request a password reset. Since the wallet software runs on their servers, providers can even pay your fees. You don’t have to understand tokens, funding, and transfers. transaction But as the saying in web3 goes: “Not your keys, not your coins!” While custodial wallets solved many onboarding issues, the wallet providers, in the end, owned the keys. We’re right back to the problems we wanted to get away from: a centralized entity that can prevent you from using your tokens, can close your account at a whim, or can shut down completely, taking your funds with them. Wouldn’t it be nice if you could have the best of both worlds? Account abstraction to the rescue! solves one of the fundamental issues of blockchain networks: the distinction between externally owned accounts and contract accounts. Account abstraction An (EOA) is an account controlled by the user with a private key. These are the traditional web3 wallets that we talked about above. An EOA has a public address and initiates transactions (such as sending tokens) with the blockchain. externally owned account A (which is also just a smart contract) is a program deployed on-chain and executed by the network nodes. Contract accounts don’t initiate transactions. Instead they respond to a transaction with an action of their own. They have no private key—they are controlled by their code. This type of account could be said to have . contract account app-custody Account abstraction combines app-custody and self-custody into a new user experience (UX), giving users the benefits of both: control of their wallets, while abstracting away the wallet (and blockchain) altogether. On Flow, account abstraction is the basis for Walletless Onboarding using Hybrid Custody. Hybrid Custody gives you the best of both worlds allows developers to create an onboarding experience for users that is nearly seamless. Walletless Onboarding The walletless user journey (from flow.com) The hybrid custody model uses account abstraction to allow —where a child account delegates control to a parent account through a , essentially allowing one account to control another. account delegation Capability Now, the self-custody account can be a parent account, giving permissions to the app account, which is now a child account. With this setup, the accounts work together, and your app can work like this: Your app creates the wallets for the users. There is no barrier to entry here—no key management, no signing transactions, no understanding of blockchain. Users can use your app, and buy and sell assets, without knowing or caring about the technical details. Your app can even subsidize transaction fees or let them fund their account with fiat such as USD. And it all happens invisibly to the user. Once the user comes back with their own wallet-managed account, your app can delegate access to the user’s account. Once linked, the user has hybrid custody – their wallet manages their main (now “parent”) account which secondarily maintains access on the app-created (now “child”) account. Since their main account now has access on the app-created account, they can bring app assets anywhere their wallet-managed account goes. They can trade your app’s assets on marketplaces or share them with friends. Yet, at the same time, since the app also has access to the account, it can still facilitate seamless UX that acts on their behalf. With this hybrid custody model, users get to experience your app right away, with minimal barriers and no risk. And later on, if they choose, they can take control of the self-custody account themselves, enjoying all the real ownership and self-sovereignty it brings. Technical details of hybrid custody and account abstraction Account Creation How does all this work? On and many other blockchain networks, an EOA is created from a public key. The key is hashed, and the first 160 bits of this hash become the address of the account controlled by that key. This makes account creation independent from the network but irrevocably ties an account to that key. Ethereum Flow uses a particular on-chain function to create account addresses. You can then add any number of keys to a Flow account, adding and removing access based on the custodian of each key. This means a transaction is required to create a new address—so you can’t create accounts offline—but it also makes Flow account ownership much more flexible. You can see , but let’s check out the crucial parts here: a full account creation example on GitHub FromPrivateKey(userPrivateKey).
  SetHashAlgo(crypto.SHA3_256).
  SetWeight(flow.AccountKeyWeightThreshold) examples.ServiceAccount(flowClient) []*flow.AccountKey{userPublicKey}, 
  nil, 
  serviceAccountAddress
)


createAccountTx.SetProposalKey(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceAccountKey.SequenceNumber
)


createAccountTx.SetReferenceBlockID(
  examples.GetReferenceBlockId(flowClient)
)


createAccountTx.SetPayer(serviceAccountAddress)

_ = createAccountTx.SignEnvelope(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceSigner
)
_ = flowClient.SendTransaction(ctx, *createAccountTx) userPrivateKey := examples.RandomPrivateKey() userPublicKey := flow.NewAccountKey(). serviceAccountAddress, serviceAccountKey, serviceSigner := createAccountTx, _ := templates.CreateAccount( First, the user creates a key pair. Pretty basic stuff. Because on Flow, you create accounts by sending an account creation transaction, we need an existing account to send this transaction. This housekeeping is the job of the . ServiceAccount The receives the user’s public key to control the new account later, but the , which signs and pays for the transaction, handles the rest. In the case of your app, you would own this service account so you could sign account creation transactions on behalf of your user, also funding the account’s creation. createAccountTx ServiceAccount Hybrid Custody Let’s get back to the hybrid custody model. Your app can create app accounts for your users and link them to a public key that your app controls. The app can then handle your user's transactions and assets and even sponsor their transaction fees, just like any custodial account would do. Later, when a user decides to dive deeper into the web3 ecosystem and get their own wallet, you can create and save a link to the app-custodied account’s , and delegate control to the user’s wallet-managed account. AuthAccount Capability You can see an example of this in the where a multisig transaction is executed by the app to link a user's account to a walletless onboarding, dapp-custodied account to the signing user’s wallet-managed account. walletless arcade example Summary It’s worth driving the point home that delegating access on the app-created account is done via a linked Capability on the account which is then provided to the user. This mechanism for account delegation is completely new to blockchain accounts, and is only possible because of the account abstraction that’s been native to Flow for years now. This language API account linking feature is a huge advantage to accounts on Flow, in addition to many other features – m-of-n multisig, re-keying accounts, etc. – which are only now beginning to be realized on other chains with their nascent, non-native account abstraction implementations. Account abstraction is a powerful feature. On , it enables a hybrid custody model that allows users to enjoy the benefits of a custodial account when they sign up, while enabling them to take the account into self-custody at any time. It’s a new – and vastly improved – user experience that hopefully brings millions more users into web3. Flow Also published here .

Web3 Onboarding is Terrible — Make it Better With Account Abstraction and Flow

(or my fork of it, ) is a backstack. Well, it is a thing that holds the , which is called . Flow Flowless technically backstack History is — you can guess it — the history of the application at a given time. This is actually just a list of objects — albeit its indexing is inverted, where returns the last inserted element, and returns the first inserted element. A stack, if you will. History History get(0) get(size-1) A  ← top , .get(0)-B-C-D element As list: [D,C,B,A] In this list, the object , , , is just a simple instance of a class with some data fields and hashCode/equals methods; also called a “value object”. It’s just a class that looks like this though D C B A A { String ; public class private final data **public** A(String data) {  
    **this**.**data** \= data;  
}  

@Override  
**public boolean** equals(Object object) { _// auto-generated_        **if**(object == **null**) {  
        **return false**;  
    }  
    **if**(!(object **instanceof** A)) {  
        **return false**;  
    }  
    **return** StringUtils.equals(**this**, **data**, ((A) object).**data**);  
}  

@Override  
**public int** hashCode() { _// auto-generated_        **return** getClass().hashCode() + 31 \* (**null** \== **data** ? 0 : **data**.hashCode());  
} } So yeah, this totally simple object that just contains a String and overrides equals/hashCode is called a . This is what represents where you are in your application. A Key In the case of Activities, this would mean that you have the following activities: DActivity, CActivity, BActivity, AActivity and , , would be in the background in (but not destroyed), while is in the front (with and called). DActivity CActivity BActivity onStop AActivity onStart() onResume() When you start in , what happens is that is put to , boots up and is placed in… actually, let me grab the documentation AActivity BActivity BActivity onPause() AActivity Activity A’s onPause() method executes. Activity B’s onCreate(), onStart(), and onResume() methods execute in sequence. (Activity B now has user focus.) Then, if Activity A is no longer visible on screen, its onStop() method executes. But in this case, I had to: 1.) check the documentation to see what’s going on 2.) the backstack is implicit, so getting from to immediately is very very difficult. You need to tinker with intent flag and hope it actually works. If it doesn’t, you might even set launchMode on your Activity to finally make it work, somehow. AActivity CActivity CLEAR_TOP singleTop — — — — - Now in the case of Flow, this isn’t so complicated. When you call Flow.get(this).set(A.create()); Then what you receive is called a “traversal” that is “dispatched”. Simply put, it tells you that something happened, and shows where you previously were in your application: , and where you are heading: . [D,C,B] [D,C,B,A] If you were in and you call , then you will get a traversal that says you were in , and you’re going to . [D,C,B,A] Flow.get(this).set(C.create()); [D,C,B,A] [D,C] What happens (the stuff I grabbed from the documentation) is , so you are in direct control of what happens. completely up to you to write This generally means that what you end up doing is: - check if you’re still in the exact same state, if yes, then don’t do anything (tell Flow that you’ve handled the traversal)- persist the state of the current layout- remove current layout- inflate a new layout- restore the state of the new layout (if state exists)- add new layout- tell Flow that you’ve handled the traversal ( ) here’s an example for a simple dispatcher — — — — — — This is actually great for multiple reasons: 1.) you don’t end up with views in the background in that are not destroyed, so you don’t have to ensure that you “reload the data and refresh” when you navigate back onPause() 2.) the views are destroyed, thus freeing up memory, which is more performant 3.) activity transitions have additional overhead, which makes them slower than view transitions (also, works on Views, but not on Activities/Fragments) TransitionEverywhere 4.) now that you have direct access to “where you are in the app”, but also “what happens when I go from here to there”, it’s actually pretty easy to set up a traversal like so: => [D,C,B,A] [C,E,B] Because it’s literally just Flow.get( ).setHistory(History.newBuilder().push(C.create()).push(E.create()).push(B.create()).build()); this How do you intend to do that with the Activity stack and intent flags? No damn clue! — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — TL;DR: is a backstack library that allows you to easily persist/restore the view’s state, and allows you to handle changes between where you are at a given moment, and where you are heading. That’s pretty much all it does. Flow (Reddit discussion thread: https://www.reddit.com/r/androiddev/comments/5h0er6/eli5_what_does_squares_flow_library_do/ ) https://upscri.be/hackernoon/

ELI5: What does Square’s Flow library do?

NOTE: I’ve deprecated Flowless (and have abandoned using Flow) in favor of what I wrote based on that from scratch: Simple-Stack . So you should keep in mind that I am no longer using this, because Simple-Stack solves quirks that I didn’t like about Flow’s design. In fact, this article probably isn’t even worth reading anymore. Read this one instead: https://medium.com/@Zhuinden/simplified-fragment-navigation-using-a-custom-backstack-552e06961257 — — — — — — — — — — — — — — — — — — — — — — — — — I’ve actually (and ), but it was rather bland. It’s time for a new and better article, a bit more straight to the point. I had also written about , but that should be considered obsolete — the architecture of Flow 1.0-alpha is much better and preferable (because it manages state persistence, while the previous version did not). written a previous article before about Flow Flowless using Flow 0.12 and Mortar The basics For those who haven’t been keeping track of just — well, nobody likes the lifecycle, and nobody likes how they work strangely with the CoordinatorLayout, and nobody likes how the FragmentManager transactions are a chaotic mess, and reading . how much Fragments have been hated for quite a while now the source code doesn’t really help So with that in mind, was created to take over what the FragmentManager intended to do — be a (like what gives you), make sure the views properly get restored on configuration change and process death; but the weird bugs that . Flow backstack addToBackStack(null) without nobody really understands Why would there be no such weird bugs, you ask? Because all transition from “ ” to “ ” is handled by — the user of Flow. State A State B you Some history, and what’s new Flow is actually quite old, although due to its lack of documentation and scary sample codes, it never really got adapted. There were . even articles about it (well, Square kinda left that hanging at Flow 0.8) In order to understand how has changed over time, let’s look at an example from that article for , and how we’d do the same thing with the latest Flow. Flow Flow 0.8 State representation Back in Flow 0.8, every view that was shown was described by an , where this object was annotated with . This screen contains the layout that should be shown when this object is set to the backstack. Object @Screen @Screen**( . . )** albumId**;** layout R = layout album_view public class AlbumScreen { private final int albumId**)** **} public AlbumScreen(int { this. ; albumId albumId = public int getAlbumId() {return albumId;}}** @Screen**( . . )** TrackScreen HasParent**< >** albumScreen**;** trackId**;** layout R = layout track_view public class implements AlbumScreen { private final AlbumScreen private final int albumScreen**, int** trackId**)** public TrackScreen(AlbumScreen { this. ; albumScreen albumScreen = this. ; trackId trackId = } @Override AlbumScreen getParent**()** albumScreen**;** public { return } AlbumScreen getAlbumScreen() { albumScreen;} public return int getTrackId() { trackId;}**}** public return This actually hasn’t changed much, other than that (and ) isn’t provided to you by the library anymore. You’re just told to use any Object, whatever Object you want; as long as it has and methods. @Screen HasParent equals() hashCode() Of course, it makes most sense for the key to still tell you what layout you’d like to build. It’s also easiest if you make your keys Parcelable (or provide a that can turn them into Parcelable, but that takes more effort). KeyParceler Without further ado, the way you’d do this now in Flow 1.0 is the following: You could also choose to provide the view’s layout identifier using an annotation if you want, you just need to also provide the logic that would extract the value from it. (Note: With current Flow 1.0-alpha, it might also be a good idea to extend _TreeKey_ instead of making a _HasParent_ annotation, if we want to make Flow handle “managed services” and reference counting — although I personally don’t use that, because I’ve had issues with it.) Navigation handling Back in Flow 0.8, you had to implement the interface, which gave you the new of objects (annotated with ), and the as to whether you went backward, forward or replace. Flow.Listener Backstack @Screen Direction @Override Direction direction**)** Object screen backstack**. (). ();**setContentView**( . (this,** screen**));** public void go( , Backstack backstack { = current getScreen Screens createView } This has changed a bit, because and no longer exist, and more importantly, Flow is no longer synchronous — it’s callback-based. This is to allow animations to be handled, and state change would be “committed” only once the animation is actually complete. And even more importantly, you also receive both the and the stack of objects. Screens @Screen previous new In Flow 1.0-alpha, you need to implement the interface (previously ), with the following signature: Dispatcher Flow.Dispatcher public interface Dispatcher {/*** Called when the history is about to change.* Note that Flow does not consider the Traversal to be finished,* and will not actually update the history,* until the callback is triggered.* Traversals cannot be canceled. * @param callback - Must be called to indicate completion of the traversal.*/ void dispatch(@NonNull Traversal traversal,   
              @NonNull TraversalCallback callback); } Which, if we wanted to stay as simple as the article was, would look like this: As for the Context magic in the middle, . that’s exactly what [Screens](https://github.com/square/flow/blob/762864967765f0f3f7f9827609f5b97fdd963a76/flow/src/main/java/com/squareup/flow/Screens.java) used to do — — — — — — — — — — — — — — — — — — — — — — — — — — — — However, it’s worth noting that back in the day, did not handle viewstate persistence. You were entirely on your own in that regard. Now, Flow provides a class to which you can persist the state of your view, which is then stored into Flow’s very own stack. Flow State History With that in mind, we ought to create a view group that contains our view which we’re currently showing (which I’ll call ), so that we can easily access the view directly, and obtain/restore its state. root With that in mind, now not only do we have a backstack, but we also have state persistence for the views. Rotation and navigating away from our view won’t remove our viewstate anymore, and Flow handles most of the work internally. Neat! :) This is also where animating between the two views would be handled — for example, we could use if the exists. TransitionManager.beginDelayedTransition() previousView Switching between application states Remember this? FragmentManager fragmentManager = getFragmentManager();FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();fragmentTransaction.replace(R.id.fragment_container, FeedFragment.newInstance());fragmentTransaction.addToBackStack(null);fragmentTransaction.commit(); Well, back in Flow 0.8, it used to be this: flow**. (new** trackId**));** goTo Track( , albumScreen And now in Flow 1.0-alpha, it’s this: Flow.get(this).set( trackId**));** new Track( , albumScreen Using makes Flow check if the given key already exists (with ), and if it does, then it sets the state back to that view — and all views afterwards have their history cleared. If it doesn’t exist, then it’s a new state, and appends it to the end of the history stack. It’s essentially , except it actually works. That’s what determines the History stack you see in the traversal. set equals CLEAR_TOP destination If you want a bit more fine-grained history modifying, Flow gives you that as well: The scary stuff from the old versions: Mortar/Dagger The old Square “big picture” The examples for Flow 0.8 looked scary primarily because of Mortar and Dagger1. If you ask me, Mortar’s state persistence through the ViewPresenter was conceptually flawed, and Dagger1 is superceded by Dagger2. Still, it might be worth understanding to know what problems we’re trying to solve, even though it’s pretty much obsolete, or handled externally by the Dispatcher implementation. @Screen**( . . )**public class AlbumScreen final int albumId; layout R = layout album_view implements Blueprint { public AlbumScreen(int albumId) { this.albumId = albumId; } ** @Override String getMortarScopeName() {return "AlbumScreen";}** @Override Object getDaggerModule() {return new Module();} } @dagger.Module(addsTo = AppModule.class)static class Module {@Provides Album provideAlbum(JukeBox jukebox) {return jukebox.getAlbum(albumId);}} And afterwards, a Presenter is defined, which receives its dependencies injected from Dagger’s ObjectGraph, retained by Mortar’s scope: @Singletonpublic static class Presenter ViewPresenter**< >** Album album**;** extends AlbumView { private final @Inject Presenter**( )** **} Album album { this. ; album album = ** And the view: FrameLayout @Inject AlbumScreen**. ;** public class AlbumView extends { Presenter presenter TextView newNameView**;** private final AttributeSet attrs**)** attrs**);**Mortar**. ( ,** public AlbumView( , Context context { super( , context inject context this); Of course, this [_Blueprint_](https://github.com/square/mortar/pull/2/files#diff-8c45305219e23e9aa32a516d557a98e4) could have also been an annotation like _@Blueprint(scope = "AlbumScreen", module = AlbumScreen.Module.class)_ . Later, it was removed from Mortar as a library. What is Mortar? BluePrint was back before the , when Mortar was bundled with Dagger1 — it was essentially a service locator where a for the was identified by a String key, this survived configuration change, and , it used to provide the hierarchical scoping of dependencies (think and with Dagger2) and seeing them within the entire view hierarchy, while also preserving them between rotations. Mortar 0.17 API quake scope LinkedHashMap scope by overriding [getSystemService()](https://medium.com/@theMikhail/system-services-are-not-just-for-the-system-ce33aab4594a#.8ym79d4y0) @Singleton @ActivityScope Mortar also took upon itself to be a “Presenter” for the views (the ), and handle the delegation of from the Activity in order to persist the state of the presenter into the Activity’s Bundle. ViewPresenter<V> onSaveInstanceState() The problems of Mortar Mortar did NOT integrate with Flow at all — you navigated forward in Flow and navigated back; and Mortar could not persist the state of the view because it never received a callback from . All view state was lost between navigation changes. activity.onSaveInstanceState(Bundle) As a result, Mortar’s ViewPresenter was flawed for multiple reasons — and this is exactly why itself started handling state persistence. Flow Flow and state persistence (beyond viewstate) But Flow only provides a direct way to save viewstate — even though it has a slot in history that would allow saving a Bundle along with the view state. While Flow doesn’t provide a way (yet?) to access this Bundle, it’s possible to use this with some package-internal logic, with which you can save the presenter state through the view to a Bundle. manually And then you can call Now your View is also able to persist its state into a Bundle on rotation. Mortar as a service locator, and “ManagedServices” Mortar also provided a way to retrieve the Dagger object graph from the scope bound to the context, and the scope could be created and destroyed manually, independent from the Activity lifespan itself. This was replaced by Square’s Flow 1.0-alpha as the and , I personally don’t use these at all. They would solve the issue of creating and destroying services, and sharing them between view states if the keys belong to the same “flow”, thus sharing resources between the views. ManagedServices ServiceFactory If this worked it would be great, but I’ve run into cryptic bugs with the “node reference counting” and — so I skipped it. TreeKey But yes, the [ServiceFactory](https://github.com/square/flow/blob/master/flow-sample-tree/src/main/java/flow/sample/tree/FlowServices.java) is what would replace Mortar. The new big picture using Flow Now that we have a backstack with state persistence, we’re able to create views that represent our active window, rather than having to rely on Activities to do it. We also have fine-grained manipulation of this , rather than trying to make do what we want it to do with magical intent flags. backstack Android Our intents are replaced by key parameters, and fragment transactions are also replaced by the keys themselves. All state change is managed by the Dispatcher, which provides predictable behavior rather than having “unattached stale fragments”. Our Activities and our Fragments are replaced by Custom Viewgroups, eliminating complexity and providing better performance. With minimal configuration, we can now create view-driven applications, like so. Activity Key View Presenter Fairly simple separation between the view and presentation — cleaner than either Activity or Fragment. Why are we still fighting Fragments, when all we really need is a separate state representation that survives configuration changes? While you can use Conductor, I have not used it. I prefer the fine-grained control that Flow provides — and directly understanding what’s happening underneath. ( : ) Reddit discussion https://www.reddit.com/r/androiddev/comments/5awo5r/saying_no_to_fragments_and_activities_creating/

Stories, News & Mentions about FLOWLIE

Flowlie’s Stories on HackerNoon