Group into separate packages

[pocorall]

Group into separate packages

[pocorall]

Certainly, common.scala has too many things to be easily grasp the overall structure. Splitting the source code file would be a natural solution to overcome this.

However, current version of the library actually has no version :D and not packaged yet. I will versioning it and upload it to the central maven repository. Then, I will split the file after that.

You also mentioned that re-positioning the helper classes to have the same package structure of Android API. I think this will arise a problem that the user always should import packages as a wildcard such as import android.view._. Otherwise, Scaloid implicit conversion for getter/setters will not work. I made Scaloid to be used easily as possible. I believe that everything is functioning by just add single line of code (import org.scaloid.common._) is a quite important part of the library.

However, I might be missing something. Let me know if you have any comment.

[pocorall]

Scaloid is now released to the central maven repository.

[guersam]

Nice!

For modularization with single line import support, we can group them into traits and provide single object extending all of them.

here's an example from Scalaz. You can import all of scalaz features at once by:

import scalaz.Scalaz._

[pocorall]

Thank you for a good recommendation. I will split the file someday later, but I have to focus on enhancing features for now. I will let this issue is stay opened until then.

[fayimora]

NIce suggestion @guersam. I think the earlier the project is modularized the better.

[pocorall]

Current snapshot code is now subdivided into several groups. Therefore broken binary compatibility.

[guersam]

3 months passed, a lot more interesting things are added - thanks again!

1. Once again, Widget.scala has grown huge and it's hard to navigate. My suggestion is to move all widgets to org.scaloid.widget package and group them into corresponding traits living in there own files as described in UI section of Google Android API Guides.
2. What was your initial idea of common package? If you want to cover overall Android API, it would be better to replace it with corresponding Android package names. We can still provide one-line import feature using the same technique.

I'm considering opening a pull request with initial structure including empty traits, but it must break the source compatibility so maybe I have to do this in my own fork.

Do you have any idea?

[pocorall]

Widget.scala is automatically generated from in-house template generator, in which I did not decided whether open-source it or not. Templating will boost adapting API changes as the Android API evolves. Splitting the file will involves huge refactoring on the template generator.

When I named common package, I thought that Scaloid will be grown to be common things and optional things.
Although Scaloid does not have optional things yet, I reserved the third-level namespace for it.

Splitting it with corresponding Android package name also involves refactoring the template generator.

I understand the importance of modular file and package layout. However, Because I have no sponsor on this project, I am very limited about working hour on Scaloid. I have to prioritize new features and documents.

I will stay this issue opened until I actually done it.

[guersam]

Sounds reasonable.

I'm still interested in modularization including package separation and multi-project implementation using SBT or Maven, like scaloid-common, scaloid-support, scaloid-extra or etc.

Could you explain a little bit about how your template generator works? Currently preparing for API change is not my main interest so I might reorganize current generated code manually, but implementing macro-based Android API wrapper (directly or via SBT plugin) is one of my (maybe far..) future plans. I need a lot to study though....

But I also respect this project's priorities. Please let me know if there's something I can help.

[pocorall]

Thanks guersam for your help!

I think that Scaloid need to be more easy and intuitive for normal Java+Android developers. There are some novel ideas that can be unfamiliar for them such as UI-layout-without-XML. So I am more focused on writing documents and publicize it to make Scaloid's advantages are more clearly understandable.

There are a lot of getter/setter wrappers in Widget.scala. All of these are generated by my in-house generator. I wrote it with PHP, because it is quick to write :-D

I have written Scaloid with a passion. However, open source cannot sustain without some financial support. Some of these are (1) self-donation from the developer (2) getting sponsor, and (3) commercializing additional components or services.

Currently, I am donating my time to Scaloid. If this project proven to be worthwhile for many peoples, method (2) or (3) should be considered.

Additional packages that covers compatibility support library or other extra goodies are some kind of the strategy (3). So I did not open-sourced the generator.

[guersam]

I see. It must be great if you get (2) to boost up..

I've been interested in proceeding with my own Scaloid fork, but it would be bad for your financial strategies.

I'm not much experienced in hosting open-source projects, (even not in closed-source) but having more committers might be an alternative to save your time (afraid of time for code review though..)

What do you think about Scaloid's license?

[pocorall]

It is always great to have many commiters for open source project. And it is also nice to have forks that implements great idea. However, cooperation is better than working separately. Please let me know your plan to grow your fork.

Scaloid is Apache 2.0 license.

[guersam]

Thanks, I agree on your point.

Currently Fragment with compatibility support is the most useful feature
for me but it's nice to have yet.

Would you find it useful if there's a SBT widget generator stated above?
It's still my main interest as a Scala/Android novice, but it must break
backward compatibility so that's why I mentioned another fork.

[pocorall]

Wrapper generator based on sbt would be a great idea! I want to help develop it, although I am novice about sbt.

[placrosse]

I could likely assist in converting your PHP generator to Scala code (for
use as an SBT plugin, or to be run separately).

On Mon, Apr 29, 2013 at 5:21 AM, Sung-Ho Lee [email protected]:

Wrapper generator based on sbt would be a great idea! I want to help
develop it, although I am novice about sbt.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-17156879
.

[pocorall]

Great! Because you are promised to help improving the generator, I will open the source under Apache license.

I will post a link to a new repository in a few days.

[fayimora]

I'm interested in contributing to the generator's conversion too. I still remember my
PHP lol

[guersam]

Thanks @placrosse, @fayimora :)

Current stable SBT (0.12.3) is built in Scala 2.9.2 which is not shipped with macro by default. In this situation, converting existing generator to Scala will be a good bridge. SBT documentation has Generate sources section, and an example from shapeless is here:

• code generator
• generate source code before compile

[pocorall]

I created scaloid-stamper project.

I just needed a working result quickly, so please understand that this is far from neat code.

[placrosse]

I think Step 1 is to convert the generator to Scala such that it produces
the exact same code now produced by the PHP generator. This makes it easy
to determine that it is working properly by simply comparing the source
code files output from each.

Once we have that, then we can proceed to make additions to the generator
(for higher level Android APIs, etc.).

Comments?

Sung-Ho, do you want this done in the scaloid-stamper project, or added
into the scaloid project itself as part of its SBT build? If we add it to
scaloid, someone can checkout a single project to create their own scaloid
library jar instead of two projects and separate steps. If we did this,
the source files that come out of the new generator would no longer be part
of the checked-in source, but instead could be built during the SBT run
before the overall compilation.

On Wed, May 1, 2013 at 1:11 AM, Sung-Ho Lee [email protected]:

I created scaloid-stamper projecthttps://github.com/pocorall/scaloid-stamper
.

I just needed a working result quickly, so please understand that this is
far from neat code.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-17269001
.

[guersam]

Currently I'm working on SBT version of the generator using StringTemplate4.

The templates are moved to src/main/st and will be converted during compilation into src_managed under target directory, which is not included in original source dir. If you want to include generated sources under src/main, adding copy phase in SBT is pretty easy.

[guersam]

If you don't want to add any external dependency, please let me know before I get too far.

[placrosse]

Either approach should work fine. Upon consideration, the Android API
doesn't change that quickly, so publishing the generator as a separate SBT
plugin shouldn't hinder anything.

On Wed, May 1, 2013 at 8:29 AM, guersam [email protected] wrote:

If you don't want to add any external dependency, please let me know
before I get too far.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-17279160
.

[guersam]

IMHO, gathering related sources into one repository makes newcomers easier to understand & contribute unless the codebase is huge. But I see your point and agree on it.

[placrosse]

I also like prefer the single repository approach, to the point of also
including and "examples" directory. Since the goal is to make Android
development with Scala simple, and I believe we can do that to the point
where it is much easier than even the other (Java-based) alternatives,

On Wed, May 1, 2013 at 8:53 AM, guersam [email protected] wrote:

IMHO, gathering related sources into one repository makes newcomers easier
to understand & contribute unless the codebase is huge. But I see your
point and agree on it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-17279973
.

[pocorall]

@guersam Using stringTemplate is awesome! Looking forward your initial contribution.

I also think that single repository or separated one has its own pros and cons. And also agree on starting as a separated plugin.

[guersam]

Although still having much more to automate, now we seem to have new basement to go further.
My ideas are:

• Flatten Android packages into corresponding files like Widget.scala, Inputmethodservice.scala under org.scaloid.common package. To keep single-point import support, we can make lowercase, underscored file names to flatten inner packages or just put them into parent files.
• Delete trait WidgetFamily and bring the members out to Widget.scala. Non-package members of android.widget will be moved into their own files.
• Keep package.scala small to have only necessary members.