Parcl Labs

parcllabs

Revolutionizing Creative Text Generation with Quality-Diversity through AI Feedback

Hello! My name is Vadim, and I am an Android Developer at Welltech. We specialize in developing mobile applications in the Health & Fitness category. I would like to tell you about our experience with navigation in Jetpack Compose. This article will be useful for those who are just starting to learn Compose or for those who are not satisfied with standard solution - the Navigation component for Jetpack Compose. Google’s History While View was being used, the (NC) became the de facto standard. The majority of developers, including us, used it and "were perfectly happy." With the advent of Compose, Google also adapted NC and recommended its use. Navigation component library When we started writing a new project on Compose, we naturally chose NC to build our navigation as we already had experience working with the library. Everything looked familiar: the same NavController and the same NavHost. The difference was that NavHost's description was in the code instead of an XML file. This new approach to navigation became a real novelty: now, instead of generating screen identifiers in the R class, we needed to specify a path with arguments (if any) in the form of a String: } NavHost ( navController = navController, startDestination = "home" ) { composable ( "home" ) { HomeScreen( /*...*/ ) } /*...*/ //navigate navController.navigate( "home" ) We immediately created a sealed class for convenience to list the screens and the logic of creating a path with arguments, as well as retrieving the passed arguments from the Bundle: } } navController.navigate(Destination.Home.path) sealed class Destination ( val path : String , /*...*/ ) { object Home : Destination( "home" , /*...*/ ) /*...*/ NavHost ( navController = navController, startDestination = Destination.Home.path ) { composable ( Destination.Home.path ) { HomeScreen( /*...*/ ) } /*...*/ //navigate The first inconvenience arose when we needed to pass arguments. In NC for the View framework, arguments were described in XML (primitive types, Serializable, Parcelable). During compilation, a class with these arguments was generated, and it was only necessary to create an instance with the necessary data and pass it to NavController. But in the Compose world, we were in for a disappointment... Passing arguments in NC for Compose and the drawbacks of this implementation To pass arguments, we need to: Describe the arguments that the screen can accept (key, type); Change the screen path with the specification of argument keys; Create a path with the necessary parameters when navigating, and; Retrieve the passed arguments from the Bundle by key. OtherScreen(param1)
} composable ( "other_screen/{param1}" , //path with args arguments = listOf( navArgument( "param1" ) { type = NavType.StringType } ) //args descriptions ) { backStackEntry -> //obtain our args val param1 = backStackEntry.arguments?.getString( "param1" ) //navigate (with param1="hello_world") navController.navigate( "other_screen/hello_world" ) We moved the logic of creating a screen URL and enumerating arguments, as well as retrieving argument values from the Bundle, into a separate class. We got this form: }

        fun getArguments(bundle: Bundle): Arguments { )
        }
    }
} sealed class Destination ( val path : String , val args : List < NamedNavArgument > ) { object OtherScreen : Destination ( path = "other_screen/{param1}" , args = listOf( navArgument( "param1" ) { type = NavType.StringType defaultValue = null nullable = true } ) ) { class Arguments ( val param1 : String ?) fun getRoute ( arguments : Arguments ): String { return "other_screen/${arguments.param1}" return Arguments( param1 = bundle.getString( "param1" ) It was convenient to use this for a while. Our graph description and navigation looked like this: But as time has passed, this approach has shown significant drawbacks: Boilerplate code (when there are many screens in the project, it starts to get tedious); It is possible to make a simple typo (in the path or argument name); Since the path is parsed as a Uri, you need to make sure that the String parameters being passed don’t include any special characters - or encode them in Url format (for example, using URLEncoder.encode); Sooner or later, you will need to pass Serializable or Parcelable. Of course, this can be done by serializing the object to String beforehand, however, writing serialization every single time is boring. Compose-destinations Over time, we became accustomed to the inconveniences described above, until one day we came across an interesting library - "Compose-destinations". After reading the documentation, it became clear - this was it! We identified the following advantages: It’s not a separate library for navigation but a superstructure over Navigation-Compose, whose main task is code generation. Since it’s only a superstructure, it can easily be used in an existing project that uses NC. For new projects, the entry threshold is low in case there is experience with standard NC. There is no need to manually describe the navigation graph (simply add the @Destination annotation to the composable function of the screen and the library will generate it). There is no need to think about how to pass Serializable/Parcelable. Arguments that are passed in String format are encoded in URL format. Arguments required on a specific screen are simply enumerated as parameters of the composable function. Additionally, if you specify the NavController, the necessary controller for navigation management will be passed. There is no need to change anything in the graph description (our file was quite large - about 1000 lines - and looking for something in it was a pleasure). There are also a few downsides: It uses code generation, which increases the project build time (for our project, this is not a critical disadvantage, and we did not notice a significant impact). It is developed and maintained by one person, so what will happen to the project in the future is unknown. Migration to Compose-destinations After weighing all the pros and cons, it was clear - we needed to integrate it into our project. The migration process was not difficult, but neither was it fast as we had a lot of screens. An example of migrating our navigation: @Destination
@Composable @RootNavGraph fun OtherScreen ( param1: String ?, param2: Boolean , navigator: DestinationsNavigator ) { /*...*/ } It should be noted that @RootNavGraph is used to indicate that our screen belongs to the default graph. If you have more than one graph, you should create your own annotation by inheriting it from @NavGraph and then use it. DestinationsNavigator is a library abstraction over NavController, and you can also use the regular NavController. After adding a new screen, you need to rebuild the project for code generation to work. Then you can use the generated graph: DestinationsNavHost(navGraph = NavGraphs.root) Concise, isn't it? Next, we will look at how to navigate to a specific screen and pass arguments: navigator.navigate(
            OtherScreenDestination(param1, param2)
        )
    } val navigateToOtherScreen = { param1 : String ?, param2: Boolean -> OtherScreenDestination is also a generated class, an instance of which we create with arguments and pass to NavController/DestinationsNavigator. Conclusion In this article, we have looked at the use of a library that significantly improves (in our subjective opinion) the use of Navigation-Compose. This solution may not be suitable for everyone - I have only shown a simple use case - but the library is at least worthy of attention. Our team would have been extremely happy if someone had shown it to us before we started our development, so maybe it will be a revelation for someone here.

Revolutionize Your Jetpack Compose Navigation with Compose-Destinations

Using LiveData in Coinverse pc — Ned Scher , Waterfall at Yosemite National Park (2015) Code in the wild is always better to learn from than slide samples. Here I’ll be sharing code from Coinverse’s Open App to showcase a live Unidirectional Data Flow (UDF) pattern which makes the app more readable, easier to develop for, and debug. The previous post, , outlines the strategy for loading a newsfeed and removing adjacent ads using UDF. This post shares both a basic live example, and a more complex structure to return multiple processes in one method using . Android Unidirectional Data Flow with LiveData MediatorLiveData By downloading the , you can run the code to explore, listen on-the-go, and watch the newsfeed of audiocast and video content. For access to features requiring authentication such as saving and dismissing content, you’ll need to implement the to set up a Firebase project outlined in . GitHub project 5 easy-ish steps Coinverse Open App — Set Up pc—My Mom’s Kenya safari (1980s) Brief UDF OverviewView Events, State, and Effects — Actions created by the user that effect the data displayed, or system level events like the app starting or stopping Events — Info that displays or helps determine a view, created in the business layer of logic State — One time user interface occurrences like navigation, dialogs, and toasts created by the business layer of logic Effects LiveData provides a simple, Android lifecycle aware, toolset to handle automatically updating data for events. LiveData Loading, Content, Error Network Requests Network requests returned with states wrapped in LiveData objects ensure that the ViewModel business logic layer accounts for the loading, successful content loaded, and error states. LCE { () ( packet: T) : Lce<T>() ( packet: T) : Lce<T>()
} sealed < > class Lce T < > : < > class Loading T Lce T data < > class Content T val data < > class Error T val View Event, State, and Effect — ContentSelected ContentSelected view event In this first case when video content is selected in the Adapter it triggers a view event in the The event is processed in the . ContentSelected ContentFragment.kt. ContentViewModel.kt (...): PagedListAdapter<Content, ContentAdapter.ViewHolder>(DIFF_CALLBACK) { contentSelected: LiveData<Event<ContentSelected>> () = _contentSelected _contentSelected = MutableLiveData<Event<ContentSelected>>() = OnClickListener { view -> (view.id) {
            preview, contentTypeLogo -> _contentSelected.value =
                    Event(ContentSelected(view.getTag(ADAPTER_POSITION_KEY) , content))
        }
    }
} class ContentAdapter val get private val private fun createOnClickListener (content: ) Content when as Int () { viewEvent: LiveData<Event<ContentViewEvent>> () = _viewEvent _viewEvent = MutableLiveData<Event<ContentViewEvent>>() {
        adapter = ContentAdapter(contentViewModel, _viewEvent).apply { .contentSelected.observe(viewLifecycleOwner, EventObserver { contentSelected ->
                _viewEvent.value = Event(ContentSelected(
                        getAdapterPosition(contentSelected.position), contentSelected.content))
            })
        } { .onResume()
        viewEvent.observe(viewLifecycleOwner, EventObserver { event ->
            contentViewModel.processEvent(event)
        })
    } : class ContentFragment Fragment private val get private val private fun initAdapters () this override fun onResume () super Because the is a video, the ViewModel updates the LiveData value of the view state with the object containing a video url. contentType contentToPlay FeedViewState ContentToPlay (application: Application) : AndroidViewModel(application) { { (event) { ContentViewEvent.ContentSelected -> { contentSelected = ContentViewEvent.ContentSelected(event.position, event.content) (contentSelected.content.contentType) {
                    YOUTUBE -> {
                        setContentLoadingStatus(contentSelected.content.id, View.GONE)
                        _viewEffect.value = Event(NotifyItemChanged(contentSelected.position))
                        _feedViewState.value = _feedViewState.value?.copy(contentToPlay =
                        MutableLiveData<Event<ContentResult.ContentToPlay>>().apply { .value = Event(ContentResult.ContentToPlay(
                                    contentSelected.position, contentSelected.content, , ))
                        })
                    }
                }
            }
        }
    }
} class ContentViewModel fun processEvent (event: ) ContentViewEvent when is val when this "" "" ( contentToPlay: LiveData<Event<ContentResult.ContentToPlay>>, ...) data class FeedViewState val ( position: , content: Content, filePath: String?, errorMessage: String) : Parcelable {...} data class ContentToPlay var Int var var val The Fragment observes the value change, and launches the Fragment to play the video. FeedViewState contentToPlay () { {
        contentViewModel.feedViewState.observe(viewLifecycleOwner, Observer { viewState ->
            viewState.contentToPlay.observe(viewLifecycleOwner, EventObserver { contentToPlay -> (feedType) {
                    MAIN, DISMISSED -> (childFragmentManager.findFragmentByTag(CONTENT_DIALOG_FRAGMENT_TAG) == )
                            ContentDialogFragment().newInstance(Bundle().apply {
                                putParcelable(CONTENT_TO_PLAY_KEY, contentToPlay)
                            }).show(childFragmentManager, CONTENT_DIALOG_FRAGMENT_TAG)
                }
            })
        })
    }
} : class ContentFragment Fragment private fun observeViewState () when if null In addition to the view state being updated in the ViewModel above, a view effect, is added and observed in the Fragment to update the RecyclerView cell that has been selected. NotifyItemChanged () { {
        contentViewModel.viewEffect.observe(viewLifecycleOwner, EventObserver { effect -> (effect) { ContentViewEffect.NotifyItemChanged -> adapter.notifyItemChanged(effect.position)
            }
        })
    }
} : class ContentFragment Fragment private fun observeViewEffects () when is MediatorLiveData — PlayerLoad PlayerLoad view event In the first case the event is straightforward because there is a view event and one piece of data, the object, returned in the view state. The event created from the , that retrieves the required information to play an audiocast, is more complicated because it requires two network requests. ContentSelected ContentToPlay PlayerLoad AudioFragment.kt () { viewEvent: LiveData<Event<ContentViewEvent>> () = _viewEvent _viewEvent = MutableLiveData<Event<ContentViewEvent>>() {
        ...
        contentToPlay = arguments!!.getParcelable(CONTENT_TO_PLAY_KEY)!! (savedInstanceState == )
            _viewEvent.value = Event(ContentViewEvent.PlayerLoad(
                    contentToPlay.content.id, contentToPlay.filePath!!,
                    contentToPlay.content.previewImage))
    }
} : class AudioFragment Fragment private val get private val override fun onCreate (savedInstanceState: ?) Bundle if null (application: Application) : AndroidViewModel(application) { playerViewState: LiveData<PlayerViewState> () = _playerViewState _playerViewState = MutableLiveData<PlayerViewState>() { (event) { ContentViewEvent.PlayerLoad ->
                _playerViewState.value = PlayerViewState(getContentPlayer(
                        event.contentId, event.filePath, event.previewImageUrl))
        }
    }
} class ContentViewModel val get private val fun processEvent (event: ) ContentViewEvent when is The returned requires retrieving information from two sources for both the file to play audio, and a converted Bitmap image to display in the notification player. PlayerViewState mp3 ( contentPlayer: LiveData<Event<ContentResult.ContentPlayer>>) data class PlayerViewState val { ( uri: Uri, image: ByteArray, errorMessage: String): ContentResult(), Parcelable {...}
} sealed class ContentResult data class ContentPlayer val val val The ViewModel could achieve getting both pieces of information by making one network request, waiting for it to return successfully, then make the second request. However, this creates more complicated and nested code. In order for the ViewModel to observe LiveData from the network requests it must be observed by the UI layer in the AudioFragment. The first network request must be observed, then within that method, the second request needs to be observed. This creates nested code within the ContentViewModel as well which gets ugly. LCE A Better Solution With MediatorLiveData A better solution is to return one LiveData object that contains both the and image using takes in two LiveData objects, returning the , and returning the image. only returns the LiveData once each LiveData item passed into the method has been populated with info, indicated by an emitted boolean in the code below. mp3 Bitmap MediatorLiveData . combineLiveData getContentUri mp3 bitmapToByteArray Bitmap combineLiveData ContentPlayer (application: Application) : AndroidViewModel(application) { =
            getContentUri(contentId, filePath).combineLiveData(bitmapToByteArray(imageUrl)) { a, b ->
                Event(ContentResult.ContentPlayer(a.peekEvent().uri, b.peekEvent().image,
                        getLiveDataErrors(a, b)
                ))
            } -> T) =
            MediatorLiveData<T>().also { result -> source1emitted = source2emitted = mergeF = { source1Value = .value source2Value = other.value (source1emitted && source2emitted)
                        result.value = onChange.invoke(source1Value!!, source2Value!!)
                }
                result.addSource( ) { source1emitted = ; mergeF.invoke() }
                result.addSource(other) { source2emitted = ; mergeF.invoke() }
            } =
            switchMap(repository.getContentUri(contentId, filePath)) { lce -> (lce) { Lce.Loading -> MutableLiveData() Lce.Content -> MutableLiveData<Event<ContentResult.ContentUri>>().apply {
                        value = Event(ContentResult.ContentUri(lce.packet.uri, ))
                    } Lce.Error -> {
                        Crashlytics.log(Log.ERROR, LOG_TAG, lce.packet.errorMessage)
                        MutableLiveData()
                    }
                }
            } = liveData {
        emitSource(switchMap(repository.bitmapToByteArray(url)) { lce -> (lce) { Lce.Loading -> liveData {} Lce.Content -> liveData {
                    emit(Event(ContentResult.ContentBitmap(lce.packet.image, lce.packet.errorMessage)))
                } Lce.Error -> liveData {
                    Crashlytics.log(Log.WARN, LOG_TAG, )
                }
            }
        })
    } =
            a.peekEvent().errorMessage.apply { ( .isNotEmpty()) }.apply {
                b.peekEvent().errorMessage.also { (it.isNotEmpty()) .plus( + it)
                }
            }
} class ContentViewModel private fun getContentPlayer (contentId: , filePath: , imageUrl: ) String String String /**
     * Sets the value to the result of a function that is called when both `LiveData`s have data
     * or when they receive updates after that.
     */ private LiveData . fun <T, A, B> <A> combineLiveData (other: < >, onChange: ( , B) LiveData B A var false var false val val this val if this true true private fun getContentUri (contentId: , filePath: ) String String when is is "" is private fun bitmapToByteArray (url: ) String when is is is "bitmapToByteArray error or null - " ${lce.packet.errorMessage} private fun getLiveDataErrors (a: < . >, b: < . >) Event ContentResult ContentUri Event ContentResult ContentBitmap if this this if this " " This allows for each of the two methods requiring a network request to handle their LCEs separately, and for one LiveData object to be observed from the in the AudioFragment. ContentPlayer () { contentToPlay: ContentResult.ContentToPlay contentViewModel: ContentViewModel {
        contentViewModel.playerViewState.observe(viewLifecycleOwner, Observer { viewState ->
            viewState?.contentPlayer?.observe(viewLifecycleOwner, EventObserver { contentPlayer -> })
        })
    }
} : class AudioFragment Fragment private lateinit var private lateinit var private fun observeViewState () //Launch audiocast! In addition to the live code I’ve created notes on LiveData and the UDF pattern including documentation notes, videos, and samples. I’m the creator of Coinverse. the app on Google Play, and me for more on Android engineering! Adam Hurwitz, Download follow

Sample App—Android Unidirectional Data Flow

Oh my god!!! is now officially supported by Android. When I was watching I/O livestream, it was the sleeping time here in India, and once I seen that lock pattern being emerged as our favorite Kotlin logo, I errupted with joy and almost wokeup my elders… Kotlin Google But it was worth it, without doubt this announcement was accepted with wide cheers and enthusiasm. And working with it since a year, this comes as acceptance and relief both for us. Thanks a lot Google. Initially I was planning this post to highlight some of small details of how Kotlin can be benifitial for us. But between 17th May and today, lot has been highlighted and written about Kotlin. By not repeating all here and writing millionth post about how kotlin is awesome about null pointer etc… I will change the cource a bit. At first I have some experience to share on some small tips and tricks that may help you working with Kotlin, and in later (keeping original idea in mind) I will announce some open source works. Some tips and gotchas. Getting started If you are starting with kotlin exploration, I suggest to start with kotlin koans. They are great tutorials to get hold on the language. Don’t start with browser, the temptation is there, you can start right away. But IMO Using IDE, you will get a better idea of language and environment then using browser. best way to start koans is in your IDE. If you can’t start koans in Android Studio, go with Intellij Idea and Kotlin Education Plugin. With Android studio preview (3.0 preview2) we could not run tests. We had couple of intellij community edition installed to try flutter, and discovered Kotlin Education plugin is nearly same way as running koans in android Converting your code. Have a shortcut to convert your files(I have `Alt+Ctrl+Shift+K`), try to have a commit before you convert your file, so you can compare and revert if needed. Start with most standalone files first, so that you have less changes to commit. We tried to convert utils file (Had all our static utility methods), it changed almost every classes in our app. We ended up reverting that changes. Keeping with above point, your presenters in MVP can be considered as standalone classes. With each presenters we had to convert only 3 classes-Presenter Interface, Presenters Implementation and View Interface. (SideNote: Just by converting presenters, we ended up reducing 1000 lines and effectively reducing all nullpointers and index related crashes) When your java classes call kotlin presenters, be open to add Nullable notation (?) in all params. It’s highly possible that java can pass null where Kotlin does not expect it to be null. And compiler won’t complain. In java, `@NotNull` annotation is forced when kotlin is not returning any null, but when passing to kotlin no kind of annotation is forced. (Can’t say about Lint or inferred annotations, I did not try them) We can convert our data classes to parcelables without plugin (It works in Latest Android Studio 3.0 Preview 5). It works perfectly as far as there are primitive types as your properties. If your class has Other type or ArrayList, parcelable intention does not generate read or write implementaion for them. It generates a `TODO()`. You can overcome this by using . this plugin Libraries. As I said in starting of this post. Android officiating Kotlin has happily changed a lot of things, including course of this post. I was to discuss more kotlin code from YAC, which tried to point out the power of this language. And since I/O those points are discussed many times over many posts. But this does not changeg sharing some open-source work which born out of YAC, or YAC gave upgrade to it. The first one is Kotlin’s port of old library , The is nearly same code that opens file browser and reads response from it in YAC app. You can use it by dropping below line in your gradle file Android External File Writer kotlin port compile/implementation `com.creativeelites:androidexternalfilewriter-kotlin:0.3` The second one is . This library is collection of extension functions I use in my projects. This library has started as fork of , which isn’t updated since last 2 years. Retaining structures of this project, I have developed KUtils adding methods and solving some mistakes as Kotlin and YAC evolved. Kutils Kaffeine I have also added some extensions and methods from Anko. When I have started, Anko was a big mammoth library for layuot, extensions and sqlite. From that day and now, anko is split into multiple libraries for peace of mind. Wouldn’t it be nice to have my aditions to anko itself? Why to copy the code and develop my own library for the sake of it? The answer is I feel anko is either stagnant or not very useful for the people who use it. I have never felt the urge of using anko out of having the extension functions. There are members in community who use Anko for layout, but for me anko is good (and official) collections of extension functions, for common things, Sqlite and Layouts. The instructions to build Anko are (For me) unclear for me whether they are for Plugin or for library as well. I have some questions, and till the confusion regarding this is cleared, I have hosted this code in Kutils library. You can use KUtils using compile/implementation `com.creativeelites:kutils:0.7.1@aar` These is it for kotlin and my libraries. In next sub-series about YAC, I will talk about how I used firebase for some trivial usecases for YAC. Originally published . here _Yet Another (Intelligent) Cleaner_play.google.com YAC - Android Apps on Google Play is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

YAC-Kotlin Wrapup & Some tips

Using “codetag” comments as productive reminders Introduction Hello there, my name is Eido, I’m a software developer and I want to ask you a question: Have you ever encountered the moment when you had a you wanted to implement that ? super duper idea while coding just jumped into your mind Guess what? It also happened to me! What are the chances?! So, you created some sort of nice comment as follows: // todo implement < > super duper idea This nice comment surely written from several good reasons, such as: You didn’t want to give it too much attention. You know it’s relevant for another part of your code. You assume it should be implemented by itself in another time. You didn’t want this “data” to be lost. The truth is, this happened, happens and will happen to you, to me, and to all programmers while coding, how wonderful! But there are some elusive problems in using this approach to remember your , what are they? super duper ideas There is no term to include this sort of comments (TODO, FIXME, etc.) Incomprehensible inconsistent short written comments “what-I-was-working-on” time wasted while reading your code either before actually coding or when returning from any break, such as lunch. Luckily, you came to the right place, and the concept of will solve you those problems: codetags use the term (or plural codetag , you can even codetag it! nice eh?) whenever referring to any sort of these code comments. From now and on codetag s Save you a LOT of “what-I-was-working-on” time waste. NEVER forget ANYTHING you are considering, want to do, keep for further implementation, currently working on etc. It’s time to take action and convene the concept of these kind of comments, which can be found almost in any software project written. Who are you, “codetag”? As you probably already understood by reading the introduction, codetag is: A widely used ad-hoc code comment markup convention to serve as of section of code that need closer inspection or review. reminder I firstly read about this subject from which originally written by Micah Elliott in 2005. In this article, we’ll improve it a little for purposes. PEP350 — Codetags productivity How codetags are used? Codetags can be written in that supports comments. any programming language I have using them for a while in Java programming language, XML, JavaScript and C#. I also find them useful while working on multiple projects at the same time (don’t ask me why, but it happened) when I used them as my reminders to what I wanted to do when coming back to a project after a few days (using DOING mnemonic). How NOT to write a codetag // fixme <incomprehensible short summary of tech important note> One of the problems in the above codetag is “data” loss — when you read a codetag that wasn’t written accurately enough the following questions start to float around: What exactly the author ? had this weird idea? for god sake how much is it lays here? meant who Those questions can be really critical because maybe the of this “codetag” was the developer of this class when it was on and is that he thinks that developers of this class should write a technology specific important implementation by code that will prevent a slowdown that most probably will appear in the future, but he didn’t had the the time to do it and there was no slowdown at his time, so he continued, perhaps moved to another project and this part left alone. author early stages, what he meant How can we avoid this elusive “data” loss? How to write a codetag Write the codetag as if you are writing it to someone that doesn’t have any idea about what you are writing, even if you write it to your own self. Use the codetag format as the following section of code (start those lines with your used programming language comment character): <CODETAG MNEMONIC>: <Codetag subject><Optional codetag multi-line message><(date)> <Author> Here is an example of a codetag which sticks to above written rules: /** * The login will happen automatically when the service starts up.* A get service status will be called.* The methods that he calls will use server responses cache.* (23/01/2017) Aurobindo Boghos */ TODO: Change client request from this server You probably ask yourself “why the hell should I write those lines and waste my time instead of continue coding faster toward my goal ?” The answer to this question is divided into two parts: By sticking to this format, other teammates and you can easily read and understand it quickly without wasting any time trying to figure out what’s going on and what’s the “poet” intention. You don’t waste your time — you can avoid the time to output (such as mnemonic, date, author and priority) that can be scripted by using custom variable text code snippets. Quickly writing well-formatted codetag in Android Studio IDE using Live Templates feature Mnemonics and their purpose There are numerous mnemonics mentioned in , the mnemonics I found the most useful for me are the following: PEP350 — Codetags — Mnemonics TODO - something that someone need to do someday (notnecessarily) in the below section of code. DOING - self reminder for what are you currently DOING (notnecessarily) relate to the below section of code. CONSIDER - reminder to CONSIDER some sort of things (notnecessarily) about the below section of code. BUG - the below section of code causes BUG. FIXME - the below section of code need to be FIXed. HACK - the below section of code is a workaround. XXX - important note for you and other programmers (notnecessarily) relate to the below section of code. CLARIFY - very incomprehensible section of code below that you need someone to CLARIFY for you. Tools So, you wrote some well-formatted codetags to save both your using snippets and your teammates precious time when they’ll read them, you’d probably want a way to those codetags so it will be much easier for you and your teammates to organize and navigate back to them, see how many codetags do you have, filter them by their mnemonics etc. super duper ideas easily manage , the following recommended tools are the ones that I’m familiar with, that will provide you the solution to easily manage your codetags: As of today — “…Organizes your codetags in a Kanban board like Trello. It integrates with GitHub issues and leverages TODO.txt syntax for metadata…”, with support to write and nicely display codetags using Markdown markup language, currently available as Atom IDE package (Thanks to ). Imdone Jesse Piascik — Organize, filter codetags and allow custom codetags syntax, available only as IntelliJ IDEA built-in tool window (including in Android Studio IDE). IntelliJ IDEA TODO You guys are welcome to that you are familiar with and I’d be happy to try and add them to the above list. share more similar tools The future Finally, after understanding the concept of codetags, how to save both your own and your teammates , and how manage them, you might already seen that we only use them as super duper ideas reminders. Currently, I don’t know if there are tools to generate the output of the purposes I’ll mention below, but you also use them for the following purposes: might Build your own/team road-map dynamically while writing your code — use the right mnemonics and right tools to create your road-map. Issue tracking marker — lays exactly at the issue specific relevant code, so you can modify the codetag format by adding additional fields such as assign to, priority, etc. (cleverly supported by with its ). Imdone GitHub integration Use your imagination while using codetags and you’ll find them useful for more than just . maybe reminders Examples /** * Also handle the login result* (29/01/2017) Demeter */ TODO: Implement Json send via socket /** * read answer most voted comment -   http://stackoverflow.com/questions/7042272/how-to-properly-implement-parcelable-with-an-arraylistparcelable#comment39567370_7042753* (18/01/2017) Eido */ FIXME: parcelable object reading and writing // // (28/11/2016) Eido CONSIDER: Do we need secret key?  DOING: Add a video which constructed from h264 aac /** * or remove by being irrelevant for the user.* (16/01/2017) Bob */ TODO: Change to user friendly message

Never Forget Anything Before, After and While Coding

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)

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 PARCLLABS

Parcllabs’s Stories on HackerNoon