The possible improvement here could be made by introducing an In-Memory Multi-Version Concurrency Control discovered first inside the “Datalore” data analysis tool [52], found then described in the «An Empirical Evaluation ofIn-Memory Multi-Version Concurrency Control» article [53] and implemented inside the “Peloton” database management system [54] in C++ language. The main idea is to keep data as a combination of separate atomic changes (differences). All the changes should be enumerated with the identifiers corresponding to data states. Thus, when the client will reconnect, the server can calculate the difference for these particular changes by two state identifiers when the connection was lost and recovered. To optimize the process of not calculation the whole difference from atomic changes for each client the binary tree-based data structure was suggested. Thus, two leaf -consecutive atomic changes are merged and kept as a parent node. Then these nodes are also merged into the parent node. There no root for this tree (as the number of edges is not determined) and it has some levels with merged data. When the server needs to calculate diff for the next reconnected client it merges edges including the furthest from leaves. The calculation benefit compensates with greater memory use. But memory consumption will be smaller than in the first suggested approach.

For simplicity the first method with possible changed data loss was implemented first together with the diffing methods described in the next paragraph. Later the diffing algorithm together with the structure of got diff entity questioned the need for implementation of planned improvement. To describe the process of applying diff after reconnection should be compared with the case of online simultaneous changes of the same data state by two different clients and possible data losses be enumerated.

Figure 12. Sequence diagram of simultaneous changes made by several clients

Let two clients got the same data state withx identifier. This case is shown in left part of Figure 12. Then both of them made some change and try to apply the corresponding diff by making a request to the server. As the server applies these changes sequentially one after another there can be a race condition for example if two client updates the same entity leaf. This collision cannot be solved by applying the different structure of server state x representation such as a tree structure of diffs suggested above. Then the applying diff after reconnection to state x can be considered as simultaneous applying this diff and another complex one consisting of a number of atomic changes made by different clients. This problem comes down to the same as with two online clients making change simultaneously.

In the next paragraph atomic changes of three types: Create new entity subtree, Update and Deletewill be described. More complex differences can be expressed through their composition. Here is a detailed look at each of the atomic changes made by reconnecting client and possible data loss.

If reconnecting client created new subtree (for example new instance of a user-defined class) the only possible data inconsistency here is if the parent subtree corresponding to all instances of the user-defined class was removed. Then after applying this diff the «hanging» entity (one leaf in the large subtree) can be got. This result will not lead to lost data at all. The case of removing the whole entity subtree seems strange, and the following possibility of inconsistence should be handled by the business logic of the client application made such changes.

If reconnecting client updated the subtree there is a chance of simultaneous updates made by other clients. As there no priority between clients and no possibility to restrict such actions (besides the security option described in 2.9 paragraph) this collision can be also handled by the business logic of the client application. The tree-based structure of server state will not also help there.

If reconnecting client removed the subtree and other clients removed it also (or maybe updated some data) - there is no lack of data at all. If other clients created something new in this subtree - the case is opposite to the reverse case described above.

Thus,there was made a decision of leaving the monolithic structure of the server data state as splitting it into a number of atomic changes will not help resolve any of the found and described above collisions.

Utilization of data diffing algorithms to reduce the size of data transferred

The prototype of the Framework receives all the data for a given entity that backend has. There is a place for obvious optimization of data transferred through the network by calculating differences between data states and transferring only them. For that purpose, the algorithm for finding a difference in data is needed. It is also needed for previously described synchronization data optimization and for keeping changes made on the client offline.

When the data scheme consisted of separate entities the idea of diffing the data was taken from the Git version control organization [55]. For finding diffs on a text it uses Myers' Difference algorithm [19] inside. The same algorithm is used also inside Android RecyclerViewDiffUtil[18] for the determination of changes in lists before representation them in UI. To apply this algorithm to the complex data entities an attempt to adopt the implementation of this algorithm to the primitive data structures (as Boolean, Integer, String and List) was made. Then it could be scaled to the complex data structures consisting of this primitive by the composition of calculated diffs.

All the types that can be used for getting diff should implement Diffable interface with two operations shown in Figure 13. T is a generic subtype of Diffable interface. d and v are parameters of corresponding functions.

The minus is operation of finding the diff between this data state and the data state given as a parameter to this operation. It returns the instance of parametrized Diff type.

The plus operation in Diffable corresponds to the operation of applying diff to existing data state and receiving a new state. It returns the instance of same extending Diffable type.

Figure 13. Kotlin representation of Diffable and Diff interfaces

Two interface types together with the commutative operation of applying diff, the not commutative operation of finding diff and superposition operation for expression of the composition's diff through diffs of included substructures can be considered as a separate algebra. However, it is rather difficult to be implemented because of the uncertainty of how to find a difference for not string primitives. Mayer's algorithm is aimed mostly on String (as a list of symbols) and does not describe how to find diff of Boolean or Integer. The superposition of diffs introduces also new data types which together with user-defined entities leads to the combinatorial explosion of possible variants. The implementation of this algorithm was left closer to the end of work over the Framework.

The changed data structure allowed to rethink the way of getting the difference between two data states. As the data state is represented as the tree, the largest common subtree of two states can be found and left parts be marked as a diff. An important advantage of this approach is that the diff can be represented as the same entity type. This allows to keep it in the same table of database and transfer by the same code of HTTP client independent of new user entities will be added.

For the new algorithm the principle of two base operations stills the same. They are getting a diff between two data states and applying the diff to one entity to receive the second one. In a new approach diff is the same tree build over Entity structure. The implementation of these operations also differs a lot. Thus, the creation of a new user-defined entity instance reflects in a new key with new data placed in the same nesting level (with all the parent nodes) and can be illustrated in Figure 14. Here the first tree is a subtree of structure shown in Figure 11 with representation of an initial state of User user-defined entity. Next is the state after the creation of a new User instance. And last is diff tree got by operation of getting diff.



Figure 14. Diff for user-defined User entity instance creation

Remove of user-defined entity instance reflects in a null value for Entity in front of the corresponding key and illustrated by Figure 15. It is important to send these null values, therefore serialization nulls for JSON transferred between client and server is crucial.

Figure 15. Diff for user-defined User entity instance removal

The last operation from traditional CRUD that changes state is an update. It can be reflected by subtree with changed leaves and parent nodes and illustrated by Figure 16.

Figure 16. Diff for user-defined User entity instance change

Shown above operations over tree data make up a finite set of atomic operations on Entity structure. More complex changes can be got by a combination of several atomic operations. As the operation of getting diff is not commutative, the order of applying these atomic operations is important except for the disjoint operations set. The resulting diff got from applying all of the previous operations on the initial tree is shown in Figure 17. This can be achieved by applying the next diff to the previous one. As for the diff is also an Entity, this apply (diff to diff) can be made by the same diff apply (diff to entity state) operation.

Figure 17. Diff for user-defined User entity instances create, update and delete

Operations of getting and applying diffs are based on a recursive algorithm of finding differences in two Entity-trees. This algorithm is crucial in the context of the whole Framework work as it used as in Client as in Server. That is why it was implemented in a test-driven development technique with writing unit tests before the implementation. The code of corresponding functions is placed in the Common module to be reused in Client and Server parts.

A similar approach is used inside the Firebase Firestore library [10]. It provides two versions of cache: in memory and based on the SQLite database. The table for keeping the cache in the SQLite consists of three columns: a path of the subtree kept, a time when this data read from the server, and the data by itself serialized in JSON. When the user makes a new request to some path it is tried to be found among the paths of kept subtrees. This organization allows cache misses and different versions (different read time) of neighboring subtrees. That can lead to contradictory data but solves the problem of reducing the transferred data easier.

The Framework's organization excludes the possibility of cache miss as it keeps the same state on the Client and the Server with the accuracy up to the last synchronization.

Splitting and securitization of data directed to different clients with organization of authentication process

The last question planned to be thought about the organization of the Framework is the security assurance. Some clients may have data that should be available only to this client and the server and that should not be synchronized with other clients.

One of possible use cases for change of access to some nodes could be some blog or news application, where two types of users - editors and readers. Editors could make their articles private while they are preparing. After articles are ready for publishing, editors change the access level to be visible to any user of the application.

Another use case is usage of the Framework for organization of private cloud application. Data from the Client is synchronizing with Server for backup but is not available for other clients.

Application data may be linked with some identifier or token given after the authentication process. This process called authorization and may be implemented by keeping the list of identifiers who can have access to the given subtree inside the entity. When the server handles data updates it filters the data according to the identifier of the current client.

For example, Firebase Firestore suggests to setup security rules only in web-console separate from interface for prime data change. To be able edit the availability of data chunks it was decided to integrate securitization mechanism inside the Entity structure.

For achieving this goal, the structure of Entity data type was extended with two additional properties: nullable creator ClientIdcontaining the identifier of client created this entity and privacy Mode which contains one of three values. They are:

- Private - it means that the entity can be visible in Get-request responses and editable only by the client with id corresponding to those written in creator ClientId property (entity's creator);

- Read - it means that the entity can be updated only by the creator but visible by any client;

- Update - it means that the entity can be read and updated by any client.

The modifier of visibility (privacy Mode) together with the creator ClientId are proceeding to the child nodes of the entity unless otherwise stated explicitly. The default value for visibility modifier is Update while default creator ClientId is null meaning that by default all entities can be visible and modified by any client. As for the Framework's security model does not assume the hierarchy of clients (for example admin roles model) the pair of security properties cannot give to child entities a less private modifier than to its parent entity.

The implementation of this model consisted of five stages. First, the Entity class was supplemented by two properties. Next, the diffing algorithm was adopted to work with these new properties correctly. The correctness was checked by an additional set of unit tests.

After that, the algorithm for data splitting and securitization was implemented. For that two functions are needed to implement. First is Entity.filter(clientId: String): Entity. It filters the incoming Entity tree for passed clientId corresponding to Entity properties and returns the Entity without private data. Second is Entity.validate(diff: Entity?,clientId: String): Boolean. It validates the diff Entity passed by the clientId on correctness according to the initial value. If diff changes subtree parts that cannot be changed by this client (properties for that are taken from first Entity parameter) the function returns false. Otherwise, it returns true. The implementationsare based on the recursive graph traversal.

The next step was the change of backend. The client's identity was secured by HTTP Basic Authentication. While retrieving the client id from the server the client passes encrypted hash of a password. The backend saves this hash together with the returned client id. After that client and server use this pair for authorization of Get and Post requests to Entity endpoint. In addition, the server was changed to apply filters to Entities that are given in response to Get requests and validate diffs incoming in Post requests. Authentication was implemented with the use of components included in Ktor Server and Client libraries.

The last step was to apply these changes on the client-side to generate and save the password before getting the client id and to add basic authentication to server requests.

Conclusions and results for third chapter

In this chapter the details of Framework' implementation together with specificities of possible alternatives were given. The conclusions made following paragraphs are:

1) Extraction of Common module and common source set in ClientLib module allowed to increase code reuse with Backend and among clients.

2) The standard use of HTTP-methods for REST API made initially was replaced by only two methods: Get for retrieving last data state and Post for sending diff (with new, updated or removed entities) to server. JSON with explicit nulls serializing was chosen as a serialization format.

3) The implementation of observable data from local Database was made in order to clients could retrieve data changes as soon as they were received from the Server.

4) WebSocket mechanism was chosen and implemented as the most appropriate for receiving updates of data from the Server.

5) To synchronize offline changes after the Network reconnection a multiplatformrm library returning Network state in observable form and supporting Kotlin Flow need. As there no ready to use solutions such library was ported from RxJava analogue and used in Framework.

6) Extraction of the client library from the client code showed the need of more complex data format for keeping user-defined entities to eliminate the need of extra code for adopting such entities in Network and Database engines. The new tree-based structure was implemented and allowed to make the algorithm of getting diff easier.

7) Mayer's algorithm of getting diff is aimed mostly on strings and lists of objects and not appropriate for other data types. Therefore, the implemented algorithm was based on recursive getting of common data subtree.

8) Additional profit of implemented diffing algorithm is that format of diff coincides with the format of data. It makes the superposition function over diff possible and eliminates the need of complex server data structure for synchronization of client data after reconnection.

9) Use of the Framework may cover more use cases with introduced mechanism of securitization of data built in core data structure and covered by Basic HTTP Authentication. The concept of private Entities distinguishes it from analogues.

In next chapter examples of the Framework use will be shown.

3. Usage of the framework on the example of a test application

Structure and UI of the test application

To demonstrate and test opportunities of the created Framework a test Android-application was created. In figure 7 in the first paragraph of this section it is illustrated as the app module. It represents a simple blog application where users can write some posts. For that two entities from application domain were created: Post and User. They are implemented in data classes with corresponding mapping functions into and from Entity class as shown in Figure 11of paragraph 3.6. Operations of Create, Read, Update and Delete for Post and Users are available.

From the user interface point of view the application consists of four screens. The first screen is a list of Posts with a floating action button to add new Post (Figure 18). The second screen contains same list of Users with button to add new User (Figure 19).

Figure 18. The main screen of test application with a list of Posts

Figure 19. Screen with list of Users

The third screen represents the form for creation or update of Post (Figure 20). It can be achieved either by tap on Create Post button or by tap on some Post in the list. Here the Post can be also deleted. The forth screen represents the User entity creation or edit (Figure 21). There is also a list of Posts connected with this User. This screen can be reached by a tap on Create User button of the main screen or by tap on some User in list from second screen.

Figure 20. Screen for Post create/update/delete

Figure 21.Screen for User management with list of Posts associated with this User

The application utilizes the end-to-end numbering of identifiers of user-defined entities mechanism of the Framework. It is organized by a combination of client id got from the server (or taken -1 if there was no connection to the server since the first application initialization) and client-specific entity id.

Adding the first entity to a new application

For initial set up of the Framework with creation of first entity the following steps should be made.

1) Deploy the Server. In base use as a standalone service with remote database it does not require additional configuration in code. It can be deployed for example in Heroku [40] or any other service supporting fat (or shadow) JAR format.

2) Include the client library in Android application.

In example the same User and Post entities will be used. The same steps should be made for any other entity.

3) Let User be the first entity of a new application. It can be represented as a data class in Kotlin as shown in Figure 22. Here shown the full set of functions needed to use the User entity with the Framework. Now we need only entity and createDiff getter properties together with the underlying diff function.

Figure 22. User data class with mapping functions

The entity property allows to transform User's properties in pair of Id and Entity to be placed in Entity tree as shown in Figure 11.

The createDiff property allows to transform new User into diff subtree corresponding to Create operation starting from root Entity as shown in Figure 14.

4) The client library should be initialized. For that the RemoteDomainClient class should be instantiated with use of application context as a parameter. Then the init function should be called with three parameters. First is a HTTP URL of deployed server (starting with http:// or https://). Second is a WebSocket URL of deployed server (starting with ws://). Other parts of URL should be the same if server code was not modified and deployed as is. Third parameter is Boolean turning output of Framework logs on or off. It can be useful for debug purposes. The full code of this step can be seen in Figure 23.

Figure 23. Initialization of client library

5) Last step is to use id generator and push a diff with new User into Framework. For that the getNewId and pushChanges functions should be called as shown in Figure 24.

Figure 24. Generation of new User id and pushing it

Now if make an HTTP GET request to server's “entity” endpoint the JSON response similar to shown in Figure 25 can be received. Here the “User” subtree was created with one instance of User with autogenerated id “1_0”.

Figure 25. JSON response after first User creation

Adding the next entity to existing application with connection between entities

For creation of instance of new user-defined entity steps 3 and 5 from previous paragraph should be repeat. Below in Figure 26shown the full code of Post class. In Figure 27shown the call of getNewId and pushChanges functions for new Post. And in Figure 28- the JSON response after Post creation. This code is similar to same for User class and can be extracted into superclass.

In this example the first Post entity is connected with first User entity by passing its id in corresponding property of Post while its creation. Connection between any other entities can be made same by passing the id of one entity as a parameter of another. It is a common way of organization one-to-many connection for document-oriented databases. This can be also used for many-to-many connection. If the entities are connected as one-to-one - one of them can include the second inside its structure.



Figure 26. Post data class with mapping functions

Figure 27. Generation of new Post id and pushing it



Figure 28. JSON response after first Post creation

Retrieving data

The data from the Framework can be retrieved in two ways: in observable form and in synchronous form (by request).

1) For retrieving data in observable form the getEntityFlow function can be used as shown in Figure 29. For example, it can be used with RecyclerView and handled by immediate reflection of changes in it, as it made with lists in sample application. As for Flow class represents lazy data source, it is important not to forget finish the call chain by any terminal function, such as launchIn to start emitions of data.

Figure 29. Retrieving data in observable form

2) For retrieving data in synchronous form, the getEntity function can be used. It does not need any other actions and can be used for example for get of last list of Users in creation of new Post form (to show it in drop down list as in example application).

For mapping of Entity instance in list of Users or Posts extension functions shown in Figure 30 can be helpful. They use constructors of this classes from pair of id and Entity mentioned above.

Figure 30. Mapping functions from Entity to List of User or Post

Change and remove data

For make user-defined class instances able to be changed or removed this classes should implement updateDiff and deleteDiff getting properties to be able generate corresponding diffs. Examples of this properties implementation are shown in Figure 22 and Figure 26.

For change or remove user-defined class instance the diff generated by corresponding property from copy of existing instance should be passed into push Changes function. The example for Post class is shown in Figure 31.

Figure 31. Example of update and remove Post instance

Data access management

To create an instance of class with limited access it is needed to fill the privacy Mode property of corresponding Entity. This can be made by replace of entity property of class with function getPrivateEntity as shown for Post class in Figure 32. Privacy Mode can be one of PRIVATE, READ, UPDATE as described in 3.9. The creator ClientId property is autofilling by ClientLib.

Figure 32. Function filling privacy Mode property of Entity

For change of privacy mode, the entity with changed privacy Mode property should be passed to updateDiff and pushChanges functions the same way as with other properties update described in 4.5. The server will check that current user makes eligible changes and will return ForbiddenClientIderror with 500 HTTP error code if not.

Sample application is implemented in 16 files corresponding to class and interfaces. From them 2 classes (Post and User) together with Interactor class related to domain level (Model), 10 classes to View layer, and 3 to Presenter layer. There are no classes for Repository, Database and Network layers as they are implemented in the library. For its integration used only small Interactor class and mappers inside data classes.

To evaluate the possible effectiveness of the Framework usage several real Android applications was taken. The mean number of classes (including interfaces) of them is 127, from them 25 are responsible for Repository, Database and Network layers. If the Framework was used while this application creation their codes could be on almost 20% less than they are. It means that developers could spend less time and application owners save almost 20% of money on their creation.

As the main purpose of the developed Framework is to help with rapid application development and not the enterprise applications there can be left some not very efficient solutions under the consumption of a rather limited number of simultaneous clients handled by the server. The goal of this work is to show the approach for the design of the most used Repository and to implement it in the Framework. After testing with real users and publishing the code in open-source there probably should be some insignificant improvement resolving corresponding efficiency and Framework design issues.

Conclusions and results for forth chapter

In this chapter the example of the blog application made with use of the Framework is shown. It's two user-defined entities allowed to illustrate most of the use cases possible with Framework. Their detailed implementation was described in corresponding paragraphs.

The possible share of code in client application that Framework allows to reduce was evaluated in 20%.

The server application is ready to be deployed and used as is with the client application build with usage of the client library.

Conclusion

The research of the problem of reducing the code needed for remote domain data usage with following implementation of the Framework allowed to achieve the goal and answer all the questions set in the Introduction. The completion of designated tasks helped to reveal the following conclusions and results:

1) The Framework for synchronization of domain data state between Client and Server was designed to fill the gap in existing libraries for Database and Network combining through Repository in Android applications. It outstands from analogues by automatic synchronization of data with the Server and multiplatform readiness. It can be used with any client architecture and open for change of implementation details.

2) The multiplatform and modular architecture of the Framework allowed to reuse not only user's code but also the code base of itself. The existing multiplatform libraries were chosen and complemented with missing ones to build a reactive unidirectional data flow inside. To implement real-time data update traditional HTTP client was combined with WebSocket. The need of minimization of client code revealed a need of more complex tree-based data storage format which also make operations with diffs easier. They were implemented with self-made algorithm base on recursive find of common subtrees. The superposition of this operations makes easier a synchronization of data after Client to Server reconnection.

3) The sample Android application showed the possibility of use of the Framework in most of common use cases. The implemented Entity's security feature allows to build services with limitation of access to different chunks of data. Estimates made by analyzing several common applications revealed a possibility of reduce near 20% of code for client application written. The server part can be deployed without changes or be included inside more complex backend applications. Platform independent client code extraction allows to easily implement other platform clients.

An important outcome became the proof of need the common code part between the Client and the Server parts. During previous research of cross-platform technologies there was an assumption that only domain entities classes can be code shared between clients and server. However, in this work the implementation of the Diffing algorithm was also included in the Common module. This allows as increase the code reuse as a decrease the number of bugs in client-server communication junction. Therefore, the made assumption was disproved.

Additional useful outcomes during the Framework implementation were contributions made into inspired or used in implementation projects [46], [56]. The open-source Reactive Network library was migrated from Java and RxJava as the underlying framework to use of Kotlin and Coroutines Flow to be used in the Framework and other projects using this stack of technologies. It is published separately [50] to be used by community.

There are several improvements that are planned to be made in future. First of them is creation of base class for common user-defined entities to reduce the code needed for making mapping with Entity. Second is extending of security feature by addition of client ids to access rights mapping in Entity to make this setting more flexible.

The insights found during the Framework implementation will be used for the preparation of articles and reports about technologies used and the process of multiplatform library's implementation illustrated by the Framework. The incoming feedback is planned to be laid into the basis of improvements of the Framework before open-sourcing its code also.

References

framework application software

1. B. Mathur and S. M. Satapathy, “An Analytical Comparison of Mobile Application Development using Agile Methodologies,” in 2019 3rd International Conference on Trends in Electronics and Informatics (ICOEI), Tirunelveli, India, Apr. 2019, pp. 1147-1152, doi: 10.1109/ICOEI.2019.8862532.

2. A. Beriukhov, “Cross-platform Mobile Applications Development Approach Based on Kotlin Native and Flutter Technologies,” 2019. Online.. Available: https://beryukhov.ru/docs/beryukhov_ma_se_1.pdf.

3. A. Pogrebnyak, “Kotlin Multiplatform in Action: More than 10 Projects for iOS and Android with Shared Code - KotlinConf'19 talk,” 2019. https://kotlinconf.com/2019/talks/video/2019/151717/.

4. A. Lampropoulos, “Mobile Application Development with reusable code,” 2017. Online.. Available: http://hdl.handle.net/11544/29140.

5. A. Beriukhov, “Customized Android App for Presentation of the Schedule of Classes,” 2018. Online.. Available: https://beryukhov.ru/docs/beryukhov_ba_se_4.pdf.

6. H. Dorfmann, “The Evolution of the Repository Pattern - Be Aware of Over Abstraction,” Jul. 17, 2016. http://hannesdorfmann.com/android/evolution-of-the-repository-pattern.

7. F. Muntenescu, “Room &RxJava - Android Developers - Medium,” Jun. 23, 2017. https://medium.com/androiddevelopers/room-rxjava-acb0cd4f3757.

8. Fior Markets, “Global Rapid Application Development Market is Expected to Reach USD 95.2 Billion by 2025,” Feb. 19, 2020.

9. StatCounter, “Operating System Market Share Worldwide | StatCounter Global Stats.” https://gs.statcounter.com/os-market-share/.

10. Google and Open Source, Firebase-Firestore - Cloud Firestore component of the Firebase Android SDK.

11. Backendless, Backendless SDK for Java and Android.

12. Dropbox and Open Source, Store - Kotlin Library for Async Data Loading and Caching.

13. Jet Brains, “Kotlin for cross-platform mobile development | JetBrains: Developer Tools for Professionals and Teams,” 2019. https://www.jetbrains.com/lp/mobilecrossplatform/.

14. Open Source, Kotlin/kotlinx.coroutines - Library support for Kotlin coroutines with multiplatform support.

15. Jet Brains, “Asynchronous Flow - Kotlin Programming Language.” https://kotlinlang.org/docs/reference/coroutines/flow.html.

16. H. Dorfmann, “Reactive Apps with Model-View-Intent - Part1 - Model,” Jan. 09, 2017. http://hannesdorfmann.com/android/mosby3-mvi-1.

17. A. Beriukhov, “Flutter as a prototype tool.” https://github.com/AndreySBer/FlutterPresentation.

18. Google and Open Source, DiffUtil.java - Android Open Source Project.

19. E. W. Myers, “AnO(ND) difference algorithm and its variations,” Algorithmica, vol. 1, no. 1-4, pp. 251-266, Nov. 1986, doi: 10.1007/BF01840446.

20. B. Wang, D. Rosenberg, and B. W. Boehm, “Rapid realization of executable domain models via automatic code generation,” in 2017 IEEE 28th Annual Software Technology Conference (STC), Gaithersburg, MD, Sep. 2017, pp. 1-6, doi: 10.1109/STC.2017.8234464.

21. Google, AppSheet - Google Sheets to App.

22. Figma, Inc, Figma: the collaborative interface design tool.

23. Zeplin, Inc., Zeplin--Collaboration and handoff for product teams.

24. T. Lou and others, “A Comparison of Android Native App Architecture-MVC, MVP and MVVM,” Eindh. Univ. Technol., 2016.

25. R. C. Martin, Clean architecture: a craftsman's guide to software structure and design. London, England: Prentice Hall, 2018.

26. Google, “Components - Material Design.” https://material.io/components.

27. Apple Inc., “UIKit | Apple Developer Documentation.” https://developer.apple.com/documentation/uikit.

28. Google and Open Source, “Widget catalog - Flutter.” https://flutter.dev/docs/development/ui/widgets.

29. Open Source, Moxy - MVP library for Android with incremental annotation processor and ktx features.

30. Badoo and Open Source, MVICore - MVI framework with events, time-travel, and more.

31. Google, ViewModelOverview | Android Developers.

32. Jet Brains, “Platform-Specific Declarations - Kotlin Programming Language.” https://kotlinlang.org/docs/reference/platform-specific-declarations.html.

33. J. Rambhia, “Redux architecture for Android apps.” https://jayrambhia.com/blog/android-redux-intro.

34. VMware, Inc., Spring Boot.

35. S. Sharma, R. RV, and D. Gonzalez, Microservices: building scalable software?: easily build and implement scalable microservices from scratch?: a course in three modules. 2017.

36. Jet Brains and Open Source, Ktor - asynchronous Web framework for Kotlin.

37. K. Yee, “Comparing Kotlin Server Frameworks,” presented at the KotlinConf 2018, Online.. Available: https://resources.jetbrains.com/storage/products/kotlinconf2018/slides/1_Komparing%20Kotlin%20Server-Side%20Frameworks.pdf.

38. Jet Brains and Open Source, “Routing - Servers - Ktor - Structured Handling of HTTP Requests.” https://ktor.io/servers/features/routing.html.

39. Jet Brains and Open Source, “Content Negotiation - Servers - Ktor - Content conversion based on Content-Type and Accept headers.” https://ktor.io/servers/features/content-negotiation.html.

40. Salesforce, “The Heroku CLI | Heroku Dev Center.” https://devcenter.heroku.com/articles/heroku-cli.

41. Cash App and Open Source, SQLDelight - Generates typesafe Kotlin APIs from SQL. .

42. Couchbase and Open Source, Couchbase-Lite-Android-CE - The community edition of couchbase lite for android.

43. Couchbase and Open Source, Couchbase-Lite-iOS - Lightweight, embedded, syncable NoSQL database engine for iOS and MacOS apps. .

44. Google, “Improve app performance with Kotlin coroutines.” https://developer.android.com/kotlin/coroutines.

45. Open Source, “ReactiveX - Intro.” http://reactivex.io/intro.html.

46. A. Beriukhov, “Lack of Android Coroutines docs or example · Issue #1549 · cashapp/sqldelight.” https://github.com/cashapp/sqldelight/issues/1549.

47. Google, Firebase Cloud Messaging.

48. Square and Open Source, WebSocket - OkHttp.

49. ychescale9, “Kotlin Flow? · Issue #368 · pwittchen/ReactiveNetwork.” https://github.com/pwittchen/ReactiveNetwork/issues/368.

50. A. Beriukhov, FlowReactiveNetwork.https://github.com/AndreySBer/
FlowReactiveNetwork.

51. N. Tahir and O. Rao, “Generating Code via Annotations in Kotlin | WillowTree,” Jun. 25, 2018. https://willowtreeapps.com/ideas/generating-code-via-annotations-in-kotlin.

52. Jet Brains, JetBrains Datalore, an intelligent web application for data analysis.

53. Y. Wu, J. Arulraj, J. Lin, R. Xian, and A. Pavlo, “An Empirical Evaluation of In-Memory Multi-Version Concurrency Control,” Proc. VLDB Endow., vol. 10, no. 7, pp. 781-792, Mar. 2017.

54. CMU Database Group, cmu-db/peloton - The Self-Driving Database Management System.

55. F. Sanglard, “Git Source Code Review: Diff Algorithms,” Apr. 01, 2014. https://www.fabiensanglard.net/git_code_review/diff.php.

56. A. Beriukhov, “Replace Store.fetch() on fresh() methods by AndreySBer · Pull Request #52 · dropbox/Store.” https://github.com/dropbox/Store/pull/52.

Размещено на Allbest.ru

...