SDK is very Large (~8MB) and has a high method count

[gemiren]

This library needs to be shrink down. Currently it has 19829 method count which is way to large.

Below is the break down of the method count taken from http://www.methodscount.com/?lib=com.dropbox.core%3Adropbox-core-sdk%3A2.0.1

Library name: com.dropbox.core:dropbox-core-sdk:2.0.1 Total count: 19829

Methods count: 9087 Dependencies: 3 JAR Size (KB): 1897 DEX size (KB): 1214 Dependencies methods count: 10742 Dependencies JAR size (KB): 1503 Dependencies DEX size (KB): 1346

[greg-db]

Thanks for the feedback!

[cakoose]

Yeah, a large number of methods can be an issue for some people.

Is it bloating your final app's DEX size? If so, ProGuard (or some other minification tool) might get rid of a lot of the bulk. Many of the methods are for the DfB API, which isn't relevant to most Android developers.

Are you running up against the DEX maximum method count?

[gemiren]

Yes, now I have to use multi Dex to compile my Android code because the v2 Java SDK adds too many methods. 19829 method count is almost one third of the 65k limit. I can image every Android app developer to be forced to use multi Dex if using this library.

Interestinglt proguard is able to shrink the methods to keep it below the 65k limit, though it still adds about 10000 methods in my case, which I think is still too high for such a library. However, that's for the release build. I don't want to use proguard to obfuscate my debug code.

I am still balancing the v2 SDK with multi Dex. It increases the apk size a lot, which I don't like. I really hope you can clean the code to reduce the method count.

Thanks.

[krieb]

@gemiren can you elaborate on which API endpoints you are using? Are you primarily using a few file endpoints, or you are using various team (i.e. business) endpoints? And are you accessing only a few fields from our responses or accessing every field (e.g. for display purposes)?

I want to better understand your use case so we can take it into consideration for how to reduce the method count.

[gemiren]

@krieb thanks for look into this issue. My use case is actually very simple. I syncs my app data (settings & database, total about 5 files) to my app's folder on Dropbox. That's all I need. Just very basic Dropbox functions, no team functions are required.

[flekken]

I am currently using beta 7 on android which has 11000 methods. The method count almost doubled in the recent versions. I am using delete, listing folder contents, downloading, using metadata info like name,path and uploading files.

[kamikat]

Android build fails when compile dropbox-sdk-java as a dependency to reach a 64k method count limit. And I found we have a lot of code handling object serialization & deserialization. What's the point handle these using a Jackson streaming parse API? Seems that every field has a Reader which is soooo verbose 😦 . Why don't you try an ObjectMapper way of implementing object serialization & deserialization?

I've tried fork the project to see if I can contribute some work, but finally I realise that the project is too complicated for me to make any change.

Please consider use any Annotation serialization & deserialization APIs as described in the README (yes, proguard configuration makes no sense to implementation of version 2.0.1). And maybe we should replace the Jackson JSON Library with other alternative JSON processing library (Jackson is feature rich but in most cases, too heavy)

[krieb]

@gemiren The method count should be slightly reduced now:

Total: 12423 dropbox-core-sdk: 10249 dependencies: 2174

More importantly, however, the library is now much more ProGuard-friendly. You should see significantly reduced method counts if you enable ProGuard. If you don't want to deal with obsfucated code, you can specify the -dontobsfucate in your ProGuard configuration. See examples/android/build.gradle:

    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            // to debug ProGuard rules
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules-debug.pro'
        }
    }

This should cut the method count down to below 2000 depending on what endpoints you are calling.

Additionally, the library no longer depends on jackson databind or annotation libraries, so that should help cut down on method count as well. The library has been heavily re-written to also be multi-dex friendly.

@kirisetsz Unfortunately using annotations forces those classes to be loaded into the primary dex of an app if it is using multi-dex. This can blow-out the primary dex and prevent an app from compiling. It is a known bug in the dalvik platform that any RUNTIME annotation on a class/field/method/etc must be included in primary dex. This is the primary reason why the library cannot make use of annotation-based serialization. Also, using ObjectMapper in general requires special ProGuard rules to be used in combination with the library for code shrinking. This can often be error-prone, as previous bugs have shown.

Finally, the massive jump in method count was due to changing all public final fields to be proper getters. This was to be more in line with standard Java style.

[gemiren]

Nice to see a drop in the method count. It's much better, though it still has a large method count. Probably a better way to bring down the method count further is to break this SDK into multiple components like the Google Play service. For example, it can break into core, share, team, etc. That's going to make this library more flexible.

[ened]

Sample dex count graph via https://github.com/KeepSafe/dexcount-gradle-plugin.

Dropbox accounts for 9558 methods. Big chunks are:

• .team: 2856
• .sharing: 2498
• .files: 2113
• .v1: 390

[chrisonline]

Any news about this? This library is too big!! Please split it in multiple parts.

I have just tried the 2.0.6 release and it has over 2000 methods more than 2.0.5 :-( Come on, please split it. I am using Dropbox only for uploading files and need a over 12000 methods count library...

[krieb]

@chrisonline There is no timeline set for splitting the artifact. In the meantime, we strongly encourage developers to use the standard android ProGuard configurations for their app development with this SDK.

You can refer to the ProGuard section of the README to make sure you add the correct -dontwarn directives. If you are concerned about ProGuard obfuscating your code and making it difficult to debug, look at the android example's debug build settings. The debug build disables obfuscation with the -dontobfuscate directive.

Let me reassure you that we are looking into strategies for distributing multiple artifacts to alleviate this issue. I just can't commit to a specific date yet.

[DreierF]

I stumbled upon the same problem, because my debug build hit the 65k limit. Slowing down the built by using proguard for the debug build was not really an option for me, so as temporary workaround I created a fork which removes the team and sharing features. The result was 5,789 methods. In case someone else wants to use it: https://github.com/dreierf/dropbox-sdk-java

[chrisonline]

@krieb Hi! 1 Year later I want to ask about any news? ;-)

[litrik]

FYI: Some time ago I have created an 'OAuth-only' fork of the Dropbox Core API. It contains only 226 methods. See https://github.com/litrik/dropbox-sdk-java

[greg-db]

@chrisonline I don't have any further news on this.

[hatpick]

Can we keep using v1 while this issue remains? When are you guys going to kill v1?

[greg-db]

We don't recommend using API v1 as it is deprecated, but it will continue working until it is retired. You can find the full timeline here:

https://blogs.dropbox.com/developers/2016/06/api-v1-deprecated/

[mguntli]

The current Dropbox-SDK-Java v3.0.5 method count is simply way too large for an Android library. Any news on this?

Dexcount collected with https://github.com/KeepSafe/dexcount-gradle-plugin for v3.0.5: com.dropbox: 24939 methods, 7250 fields

[greg-db]

No news on this, sorry! We still recommend using Proguard.

[chrisonline]

As mentioned above we should use ProGuard to optimize it. But also after using ProGuard I have classes from v1 and classes from v2 like sharing, team, paper and so on!

How can I remove this on release build to lower the Method count?

[greg-db]

@chrisonline I don't have an update on this, but I'll check in with the team.

[tprochazka]

It looks that its never-ending story. I have currently 3.0.3 In my project, jar files have 3.5 MB. I was thinking about the update. The latest version is 3.0.11. I told great it should be just bugfixes. Then I realize that it has almost 8MB. Really? Especially on mobile devices, it is not an acceptable size. I'm expecting that 500kB must be definitely enough to upload and download files to some server. Especially when OKHttp is used.

[handstandsam]

Version 5.3.0 is at 7.79 MB which is very large. This is a result of generated Java code that is very verbose. This generator was originally written in 2015 here https://github.com/dropbox/dropbox-sdk-java/commit/a535411e4f886dc61667e9d7b60325ec1385a4d9 and should be updated. I'll tag this as something we want to address in a future version.

These are the largest class files which are very, very large.

This EventDetails generated source file is 1.8 MB uncompressed, and 40,000 lines long. https://github.com/dropbox/dropbox-sdk-java/blob/8b7d6b902a2394f0ef27ac53187ba388e6baf280/dropbox-sdk-java/generated_stone_source/main/src/com/dropbox/core/v2/teamlog/EventDetails.java