Code Review LINES OF CODE 232K AntennaPod SIZE

AntennaPod is an easy-to-use, flexible open source Android mb manager written in Java language. The current version 8 published on is 1.7.2b of 05/27/2019. The minimum ​ supported version of Android is Ice Cream Sandwich (4.0.1, API level 14).

MOBILE TECHNOLOGIES & FRAMEWORKS

1

Contents

Overview 3 Architecture 4 ​ ​ UI 5 Multithreading 7 ​ ​ Resources 8 Tests 9 ​ ​ Code Quality 10 Appendix A 11 ​ ​ Recommendations 12 ​

2

Overview

6 issues 6 issues 8 issues Crit​ ical Rec​ommended App​ roved ​

3

Mobile Architecture

General The application has an interesting, yet far from ideal architecture. The developers divided it into Recommended two modules, core and app, which indicates an attempt to create a flexible application structure, reminiscent of the principles of Clean Architecture. At the same time, a full-fledged implementation of this approach provides for the separation of at least 3-4 layers: for example, entities, use cases, interfaces, frameworks. This would allow realizing 3 main goals of Clean Architecture: testability, independence from UI, independence from data sources, and libraries.

Dependencies The application uses singletons to access important resources, in particular, the Application Recommended context and SQLite database. Because of this, there are implicit dependencies that lead to a deterioration in the understandability of the code, and they complicate testing and make the architecture more connected and rigid. The principle of single responsibility SOLID is violated. For example, the PodcastApp class method getInstance () is used in the core module. In essence, the meaning of the division of an application into modules is lost, since they cannot be reused and separately tested.

Java version The application uses the version of Java 1.8 - the most common among the current versions of Approved the language. This reduces the entry threshold for new developers. ​

4

Support libraries For compatibility with older versions of Android, support libraries v.27.1.1 are used. They are Approved quite heavy, and their further support has ceased. Now there is an alternative - the use of ​ libraries AndroidX, which offer a more flexible selection of the necessary components.

Mobile UI

Activities and In the app module, activities and fragments are responsible for the main logic, which turns them fragments into God-objects — classes that are critically overloaded with tasks. Because of this, the overload processing of turns of the screen becomes more complicated; the classes themselves grow and turn into poorly readable ones. Modern approaches in Android development recommend Critical separating the UI logic and working with data using delegate allocation (Presenter or ViewModel).

Native views The application uses primarily native Views from the Android SDK. This provides a guarantee of Approved correct operation on various versions of the platform and various types of devices. Custom Views ​ are added only in certain justified cases.

NPE check In the majority of activities and fragments, when accessing the actionBar, a check for a Null Critical Pointer Exception is not performed, which is fraught with the application crashing in Runtime. The same situation occurs when one appeals to the host activity of the fragments. You must add a null check.

5

WebView In AboutActivity, WebView is used to output complex content into which a pre-built web page Recommended with the content is loaded. The screen is visually different from other screens of the application (Material guidelines are violated), it works more slowly. A better approach would be to lay out an XML-screen layout.

NPE in adapters In the PodcastListAdapter and TagListAdapter classes, you must add a null test when using Critical LayoutInflater.

Mobile Model

Podcast entity The Podcast entity class is stored in the adapter itself. This violates the principles of SOLID and Critical complicates the understanding of code. It is necessary to transfer it to a separate class.

6

Mobile Multithreading

RxJava 2 Approved RxJava 2, a very powerful library with good documentation and various methods to ensure ​ asynchronous work and a reactive approach, is used to ensure multithreading in the application. AsyncTask The usage of AsyncTask (for example, in the GpodnetAuthenticationActivity class) can cause Recommended memory leaks. Non-static inner classes have an implicit reference to their outer class. If this external class is, for example, Fragment or Activity, then this link means that the long-running handler/loader/ task will contain a reference to the operation that does not allow garbage collection. Similarly, direct field references to actions and fragments from these longer instances can cause memory leaks. It is better to use RxJava 2 for asynchrony.

Disposable Disposable object is not saved anywhere. As a result, Disposables cannot be undone resulting in Recommended memory leaks and incorrect data. This is necessary to unsubscribe Disposables when not needed.

The easiest way to do this is: ● create private CompositeDisposable compositeDisposable = new CompositeDisposable(); object in host class and add all Disposables to it. ● execute compositeDisposable.dispose(); command when you do not need subscription anymore.

7

Mobile Resources

Localization The string resources of the application are stored in a separate file, which meets the quality Approved requirements of Android applications. There is localization in 50 languages. ​ Values Approved The key values for the application work are rendered into separate XML files (styles, colors, ​ dimens), which makes them easy to find and edit. Vector and raster The application has both raster and vector icons. Part of the raster icons can be easily replaced images with vector ones, which let reduce the size of the application and achieve the same display Recommended quality on the different types of screens.

8

Mobile Tests

Approved The strength of the application is the UI coverage of the main functionality tests. The well-known ​ and well-documented Espresso and Robotium libraries are used. This is definitely the right approach to support.

9

Mobile Code Quality

Names The application has a clear package structure. All classes, interfaces, and variables have Approved recognizable names that are easily understood by a third-party developer. ​ Comments Most classes are provided with comments describing their functionality. Key techniques are well Approved commented, as well. ​

Deprecated The deprecated methods are used. They are placed to the SDK to support legacy code, but there methods are more optimal alternatives. Recommended See Appendix A below

10

Appendix A Classes with deprecated methods

1. AllEpisodesfragment 11.MainActivity 2. AudioplayerActivity 12.MenuItemUtils 3. CompletedDownloadsFragment 13.PlaybackHistoryFragment 4. DownloadLogFragment 14.PodcastListFragment 5. EpisodesApplyActionFragment 15.QueueFragment 6. FyydSearchFragment 16.QueueRecyclerAdapter 7. HtmlToPlainText 17.SearchFragment 8. ItemFragment 18.SearchListFragment 9. ItemlistFragment 19.TagListFragment 10.ItunesSearchFragment 20.VariableSpeedDialog

11

Recommendations

Fix, first of all, critical bugs. Perform recommended fixes refactoring in the following sequence:

1. WebView 4. Vector and raster images 2. Deprecated methods 5. Dependencies 3. Support libraries 6. General

12

Total estimated resolution time: 133-183 hours ​

Hourly Breakdown Man-hours

Task Optimistic Realistic

General 36 48

Dependencies 24 32

Support libraries 8 12

Activities and fragments overload 24 32

NPE check 4 6

WebView 8 12

NPE in adapters, Podcast entity 1 1

AsyncTask 8 12

Disposable 6 8

Vector and raster images 6 8

Deprecated methods 8 12

Project management 10 14

Total 133 183

13

Resolution will take If we start on We’d deliver by 18 working days 08 july 2019 31 july 2019

Redwerk.com [email protected] WhatsApp Skype:redwerk.com

14