search

freeCodeCamp / chapter

A self-hosted event management tool for nonprofits
BSD 3-Clause "New" or "Revised" License
1.92k stars 360 forks source link

Feature - Mobile client #20

Closed LukasAnda closed 4 years ago

LukasAnda commented 4 years ago

I think we should discuss whether to use full native solution (Kotlin/Swift) or try Flutter for making apps. Personally, I do not think Ionic or other platforms relying on C# or JS are good for this project.

kaushalgautam commented 4 years ago

Ionic works with react now. I don't know if it's ready for prod yet though. https://ionicframework.com/docs/react/overview Ionic works pretty great with Angular. If it delivers the same with react, @LukasAnda, why do you think it's a bad idea?

bernhard-hofmann commented 4 years ago

I was hoping the site would be a mobile first PWA. This would mean there's no need for a dedicated mobile app. For example, I'm writing this on my phone without a GitHub app.

What features are you considering that would require a device specific app?

kaushalgautam commented 4 years ago

I completely agree with going for a PWA. I mentioned Ionic because I figured @LukasAnda wanted to go with making native apps using Kotlin/Swift.

LukasAnda commented 4 years ago

Well first off maybe personal preference because I wanted to help with development and I am an Android developer. Then, I think the native approach is more stable.

jatinhariani commented 4 years ago

Strongly recommend going native, especially if we are serious about building a serious alternative to Meetup. - I have experience building Kotlin and Swift based apps and can offer help for both.

vuksa commented 4 years ago

I would also prefer going native. We can even go Kotlin multiplatform and share common code and business logic layer between the iOS and Android apps.

kaushalgautam commented 4 years ago

Developing native apps will increase the contribution complexity. FCC relies on web tech (JS based- react, angular, what have you) that has easy access and low setup complexity. Especially for Apple devices, those without apple products cannot develop that easily. And as @bernhard-hofmann asked before, how will a native app trump over PWAs in our case? I believe the requirements are simple enough for a PWA.

Overall, going native might be a speedbreaker in terms of development and community involvement. Please correct me if I'm wrong 😀

vuksa commented 4 years ago

@kaushalgautam Why do you think that there won't be enough mobile devs joining this quest? :) I don't have anything against PWA, the only thing is most native mobile devs might not be able to provide a full contribution there.

In the end, as Quincy Larson said, we might have multiple mobile app projects and the best one will be selected as default one.

kaushalgautam commented 4 years ago

I get your point. @Vuksa. Of course, the best solution should be adopted and I don't underestimate the number of mobile devs that would step up. That being said, I just don't see a need to go the more difficult, deviated and less accessible way when there is no strict need for it. I have to make a case, the rest is up to the community and maintainers to decide :)

Zeko369 commented 4 years ago

We should definitely start with a PWA. But what's wrong with react-native? Do we really need native for this?

kelset commented 4 years ago

👋 I would love to help with this - from my experience as an organiser having a mobile app would surely make life easier (ex. you have the tickets & guest lists offline).

I am also proposing that we use React Native for this since:

In particular, I think that Expo would be enough for this - it's quite powerful, more reliable than RN per se and offers a series of tools to make it easier to test & publish apps.

(also, I'm heavily involved with the RN open source ecosystem and I would love to help with this)

espipj commented 4 years ago

As I've read, the front end of the Web is going to be done in React, seems to me sensible build a multiplatform app with React Native, so that we can reuse the components. In terms of the PWA seems like an amazing idea as well (easier to get people in, nothing to install, no store interference), and react native already has react-native-web which provides an "easy" way to implement that. The new Twitter client for both mobile and desktop is a great example of what react-native-web is, and to be honest I don't see many performance issues with those PWA.

Just seen @kelset comment (he basically read my mind), and fully agree.

chaotic-stump commented 4 years ago

So long as it has a good web mobile site or at least doesn’t continuously spam users to install another app.

shangeethsivan commented 4 years ago

I would vote for Flutter if we have enough devs out here who are interested. Else we can go with native(Kotlin/Swift). Recently our team worked on app for a small fest which was totally developed in flutter -> https://play.google.com/store/apps/details?id=com.poshmark.poshfest&hl=en

If it is native we should be very fine with everything right from architecting the app. But Im not sure about flutter.

bernhard-hofmann commented 4 years ago

I would hope we'll have enough Devs from all camps involved for the tech stack to not be an issue.

My concern is the selection of stack and native vs. PWA before we agree the functionality / requirements.

If we start with an agreement on what we want users to be able to do, we'll be better equipped to make decisions on native vs. web.

That being said, I liked the idea that all client apps should use a common API, and we let nature take its course to find the most loved client/s.

chaotic-stump commented 4 years ago

This isn’t really a this vs. that issue. MVP a mobile first site and a native app as supported then let users pick what they want, instead of forcing them into one or the other.

tbass134 commented 4 years ago

I think native is the way to go as well. I work on IOS and looking to help out

Vanethos commented 4 years ago

I'd like to share my opinion on the topic:

Since this is an open-source project and we want to deliver the MVP as soon as possible with the highest standards at the same time, I'd recommend Flutter.

Not only from my personal professional experience but because Flutter has worked in two different open-source projects that I'm helping maintain, two apps that are created for non-profits:

https://github.com/FogosPT/fogosmobile https://github.com/FlutterPortugal/vost-app

The advantages are clear:

If this is the chosen path, I can help creating a structure for the project similar to what we have in the VOST project.

allella commented 4 years ago

If someone is looking to attract more of the folks with the related skills for this feature then we've been logging the various skills from people in the Discord channel. Also, folks are posting directly on the Github thread.

So, see the list of volunteers and skills at https://github.com/freeCodeCamp/chapter/issues/11#issuecomment-542309409 and try to connect with them as needed.

henrymoulton commented 4 years ago

I agree with the decision to focus on web first and let it be a free for all on which platform to build the mobile app in:

We have a lot of choice in the landscape:

Have I missed anything/anyone?

kpgalligan commented 4 years ago

Kotlin Multiplatform, but I'm super biased.

brianrichins commented 4 years ago

I did a ton of research on the technical and market aspects of PWAs a few months ago (slide deck, video) - I think they are always an easy way to add a lot of power, since they basically only require adding a web.manifest and a service worker. They also can do nearly everything a native app can do; can't think of any missing feature this project would need, actually.

I would vote for adding the PWA features to the MVP web version, which should be super easy to wrap in a native framework to get in the native app stores.

The real power comes in pushing notifications (which a PWA can handle) - I don't see any issues discussing that feature yet...?

kpgalligan commented 4 years ago

PWA's solve a non-problem, which is distribution. If the goal was a web MVP, I'd just go directly to wrapping the web code for a hybrid app, or later worrying about PWA, but not complicate the development now. MVP first, refactor later. I run a mobile shop, though, so my perspective may not be applicable.

cameronsr commented 4 years ago

Question having worked on the hardware side of mobile, but not the app side. How bandwidth intensive do you believe this may be? Thinking from a standpoint of if we want to get this everywhere eventually, not all potential users will have access to 4G or 5G networks. Would there be a feasible way to test/optimize a mobile app for lower bandwidth availability?

kpgalligan commented 4 years ago

Low? It's a data app, and not a live updated data app. Maybe media in the form of images if you're trying to replicate Meetup features (although the more content people can post, the more monitoring will be an issue. Images especially)

isubasinghe commented 4 years ago

👋 I would love to help with this - from my experience as an organiser having a mobile app would surely make life easier (ex. you have the tickets & guest lists offline).

I am also proposing that we use React Native for this since:

* it's not a performance heavy use case so no need for full native

* the web client is going to be in React

In particular, I think that Expo would be enough for this - it's quite powerful, more reliable than RN per se and offers a series of tools to make it easier to test & publish apps.

(also, I'm heavily involved with the RN open source ecosystem and I would love to help with this)

I like the idea of React Native, we should be able to abstract our business logic in redux. And use React only to render.

brianrichins commented 4 years ago

PWA's solve a non-problem, which is distribution.

Distribution is only a non-problem for native apps since their only channel is the native stores. Web apps have to be reachable everywhere, and PWA tooling broadens the reach quite a bit with a tiny amount of user education.

They also provide some simple offline caching, which helps with bandwidth and performance (both important for something intended to be super low cost to run), and provide notifications like reminders and push, which drives user engagement (vital for this kind of application).

iansltx commented 4 years ago

^ In addition to the above, given that we're talking about self-hosted Chapters, you'd either have to have a native client that has the ability to connect to (and handle auth to) an arbitrary API...or one or more PWAs that can be added to the home screen right from the site as a user is browsing. The closest analog here is Mastodon instances IMO, and in their case the PWA setup worked quite well when I last played with it (granted, I'm on Android, where PWAs haven't been third-class citizens since roughly 2008).

Utkarshbhimte commented 4 years ago

I do agree with @iansltx if we are talking self-hosted chapters, nobody would want to download native apps for each of chapters and I think PWAs can be much lighter and easy to discover and distribute.

Vanethos commented 4 years ago

Why not have multiple instances inside the same app?

What I mean is something like discord, you have an app with multiple servers running and you can join in one if you have the invite link or if someone invites you.

I have worked in events apps before, and let me tell you, it can be a bit cumbersome to have 20+ apps in your phone. And then next year the organizer wants to change the name to "CompanySponsoredByX" and you have to download yet another app.

Centralizing it all would be a better option, in my opinion.

iansltx commented 4 years ago

@Vanethos Do you want ~ants~ Meetup-but-by-another-company? Because that's how you get ~ants~ Meetup-but-by-another-company.

In all seriousness, API-wise you could build a mobile app that reaches out to the various Chapter instances by URL, authenticates to each, and syndicates everything in one place. But the access pattern wouldn't look like Discord (because Discord is a centralized thing where you have one identity across the board). It would look more like Slack than Discord, except each server would be completely different ('cuz self-hosted). So really more like a multi-provider-inbox email client.

vuksa commented 4 years ago

I like the idea of having one app that communicates with all "meetup" services. Having multiple apps would be heavy and non-practical especially if you have in mind that many of us have up to 15 meetup groups that we are currently joined in. I agree with @iansltx, it would be more like the slack app, where you could join "meetup" via invitation.

Developing the MVP of an app that supports this definitely wouldn't be that trivial and quick. Also, +1 for @kpgalligan, I would try native and Kotlin Multiplatform on this, although I wouldn't have anything against Flutter either.

So what is the general plan, should we have two teams where one is developing a native app and another that develops cross-platform app? It is clear that we have mixed opinions here if we should go native or cross-platform.

tomByrer commented 4 years ago

In the manpower time spent on this topic, someone could have hacked a responsive version of the website, & added a PWA in an extra hour or 2.

Honestly, please just make sure the API rocks, & let whomever want to write native apps spin off their own team.

kpgalligan commented 4 years ago

@brianrichins Agree to disagree. PWA's just haven't really had the traction people want, for reasons. Mostly iPhone, but that's a long debate. I don't agree that making something work well on mobile is just a couple little tweaks. It's far more complex. Also, caching is the most efficient way to have stale data in your app. That is a complex topic, very much so for an app focused on data.

If it were just that simple, nobody would be making native apps. The world is just not that way. I'm not saying PWA is bad, but should probably not be a focus on day 1, and it's not as simple as you're saying it is.

I say that with a decade of experience in mobile, and spending 100% of my time researching "cross platform" related topics.

isubasinghe commented 4 years ago

I've had experience with building PWAs, imo it is probably too immature still. I have come across an issue that was opened in 2015 but the fix only came mid this year in Chrome 76. Be prepared to run into issues like this, if going the PWA route.

adrienshen commented 4 years ago

An additional observation point. PWAs have much greater popularity in places like India, SE Asia where the phones are lower powered and data plan relatively more expensive in terms of purchasing power. Given that FCC is a world wide mission, I think there's a benefit in PWA here.

With that said, as long as there's a solid API, I don't see why there can't be both PWA and various mobile clients. I mean hackernews has about a dozen clients for people to pick and choose.

Dev.To is another that started out as PWA and eventually built native mobile apps. I think users should have to option to choose their preferred clients given their hardware and data limitations.

iansltx commented 4 years ago

At the end of the day, we have a ton of eyes looking at this. As soon as we get a reasonable API, there's nothing preventing parallel development of platform-specific native, cross-platform, and web-centric clients to said API. I'm sure that there are a dozen folks who made intros in #11 who have played with full-on PWA stuff, and several who could build a native mobile app for one platform or another. So once there's an API, or at least an API spec that isn't a moving target (we aren't there yet), dev client-side can happen in parallel by folks who know what they're up against on each platform.

shirakaba commented 4 years ago

As soon as we get a reasonable API, there's nothing preventing parallel development of platform-specific native, cross-platform, and web-centric clients to said API.

I think that this is inevitable, whether by the community as a group effort, or by individuals. There are plenty of competing Hacker News clients, for example.

Like @kelset , @espipj , and @isubasinghe, I cast a vote for React Native. Not least because it's based on React (which has been agreed upon as the UI runtime for the web implementation), but because React Native has the broadest platform reach: iOS, Android, tvOS, Android TV, Web, macOS, Windows, Linux, and more. Most of these are used in production (tvOS by Salesforce, I believe; Web by Twitter; macOS & Windows by Microsoft). I've also produced apps with React Native Web and React Native macOS myself, so I can attest that they're not just good on paper; they work in practice as well.

By using React Native, we can have a singular uncompromising client codebase, rather than fragmenting it into several different projects that fall out of step every time the server-side code is updated. What's more, the language of React Native is JS/TS, which is familiar to both web developers and cross-platform developers alike. JS is renowned for its comprehensive package ecosystem, and the React Native package ecosystem is particularly comprehensive (many packages even extend support to React Native Web, such as React Navigation).

For lacking all of these benefits, I would vote against Flutter, as – to my understanding – it is only practically a solution for iOS and Android, with Web and desktop support being far behind that of React Native. The language, Dart, will be different to that of the JS-based web client, so it would create a communication barrier between the mobile and web development teams (not to mention killing the possibility of code-sharing). Lastly, it is a relatively new framework, so I would expect there to be a relative lack of expertise in it compared to other frameworks (though this may be contentious).

And for much the same reason of lack of code-sharing, I would vote against purely native development as well.

freitzzz commented 4 years ago

I understand that building a PWA could be easier than a native app, but from my POV the native app would be more beneficial in terms of performance. Faster loading of the app in old mobile devices, (My smartphone for 3 years was a SAMSUNG A300 2015 edition and opening the browser or a PWA was a pain in the ass in terms of loading speed) and faster UI rendering

Also if the community decides that a native app is more beneficial I suggest Flutter as the framework to be used and vouch @Vanethos advantages of going with Flutter

finisher1017 commented 4 years ago

IMO the MVP should be a mobile optimized web client. That way we can focus on the API and finding a graphical layout that works before possibly expanding to other technologies.

shirakaba commented 4 years ago

Mockups for the MVP are being discussed in #114 . The latest comment at the time raises a concern about CSS Grid's lack of backwards compatibility, and touched upon the issue of low-conformance and underpowered devices being popularly used in certain areas around the world.

I'd like to open discussion on how best to cater for such low-spec devices and flaky network conditions, as this wasn't a clear requirement from the beginning (please clarify if we have a stance either way on this). It is an essential consideration for the mobile client (so I'll raise the discussion here), but likely overlaps with any considerations for the web client; the desktop client is probably less of a concern in this respect.

William Imoh gives an excellent presentation highlighting the prevalence of poor network conditions in Africa and how to design around them: Slides; video.

As for low-conformance devices (i.e. old, cheap ones), I imagine that more compatibility can be enjoyed by creating a (native) mobile app than a web-based PWA, but maybe that's wishful thinking.

So far I have advocated for React Native (and React Native Web), and I still think that it fits as a solution in these cases – the Twitter client is based on RN (for native mobile) and RNW (for web), and Twitter has long been a favourite tool for communicating over poor networks with arbitrary devices. If the RNW client is found to be too sluggish for low-spec phones, an RN-based architecture would allow mobile users to just pick up the React Native (native) equivalent of the web app instead.

kpgalligan commented 4 years ago

Twitter as in the company's client app? I know several current and former Android developers at Twitter. I'd be amazed if that was true. Facebook barely uses RN. I think the marketplace did at one point. The rest of the app is fully native. RN for mobile is somewhat of a personal preference choice. It's generally much better on iOS than Android. I don't really understand why RNW exists. RN exists because React for web is so popular.

shirakaba commented 4 years ago

Twitter as in the company's client app? I know several current and former Android developers at Twitter. I'd be amazed if that was true.

It's certainly made in React Native Web (it has been since 2017), and the mobile app is certainly made in React Native. See the front page of the repo:

Who is using React Native in production web apps? Twitter, Major League Soccer, Flipkart, Uber, The Times, DataCamp.

You can examine the source code for the Twitter website and see that there are mentions of React Native in its vendors~main.*.js file. The repo maintainer was previously the tech lead for the Twitter PWA, so you can regard React Native Web as having been made by Twitter, for Twitter.

RN for mobile is somewhat of a personal preference choice. It's generally much better on iOS than Android.

I can't report whether it's any better on iOS than Android, but regardless, it's the state-of-the-art for production-level native & web code-sharing (and honestly, works remarkably well – I use it myself).

I don't really understand why RNW exists. RN exists because React for web is so popular.

React Native Web exists to allow you to use the same JavaScript or TypeScript code to describe both a PWA and a React Native (thus: native iOS/Android mobile) app. In the same spirit, there are also other projects such as "React Native macOS" to allow one to build a macOS app from your singular React Native codebase. Due to these projects that add extra platforms, React Native should be regarded as platform-agnostic app framework rather than just an iOS/Android app development framework.

Of note, regarding the question of suitability over poor network conditions: I found that Addy Osmani himself reports that the Twitter React Native Web app works great even on mobile devices over a 3G connection. Can't get much higher advocation than that.

allella commented 4 years ago

144 aims to figure out support web browsers. I suspect that's relevant to the latest mobile conversation, so linking this post.

QuincyLarson commented 4 years ago

This issue is on the roadmap, which means we will get to it after our MVP. I will close this issue for now so we can focus on resolving our non-roadmap issues first.