Meeting Minutes/2020-05-20 Mobile Discussion - Revision history

Guaka: {{meeting-minutes}}

2022-10-28T15:52:30Z

← Older revision		Revision as of 15:52, 28 October 2022
Line 1:		Line 1:
			{{meeting-minutes}}
	Who: Michael, Theo, Nick, Mikael		Who: Michael, Theo, Nick, Mikael

Guaka: mediawiki uses * for ul lists, not -

2020-05-24T12:46:12Z

mediawiki uses * for ul lists, not -

← Older revision		Revision as of 12:46, 24 May 2020
Line 6:		Line 6:
	What: React native mobile app; next steps?		What: React native mobile app; next steps?

	- Michael would be focusing on writing a react native proof of concept with some basics		* Michael would be focusing on writing a react native proof of concept with some basics

	- Longer term goal to write Trustroots features in native way in mobile app, vs having them accessible via webview		* Longer term goal to write Trustroots features in native way in mobile app, vs having them accessible via webview

	- For now just write proof of concept with react native, and decide/think about if to use webview later on		* For now just write proof of concept with react native, and decide/think about if to use webview later on

	- Start in new repository to keep it lightweight, consider in longer term to bring it into `/trustroots` repo to have monorepo approach. Starting in separate repo just is easier and we don't need to deal with any complexity that e.g. dealing with CI setup might bring. Monorepo can be useful way to encourage code-sharing on data-layer level across web & mobile.		* Start in new repository to keep it lightweight, consider in longer term to bring it into `/trustroots` repo to have monorepo approach. Starting in separate repo just is easier and we don't need to deal with any complexity that e.g. dealing with CI setup might bring. Monorepo can be useful way to encourage code-sharing on data-layer level across web & mobile.

	- Start with Expo.io framework as the current app uses it as well and it's easy to jump to development with it/implement notifications etc. All the features might not be able to doable in expo in long term, so at some point we might need to drop it out. Nobody has strong feelings about keeping it; it's primary use was to ease up getting something out with little effort.		* Start with Expo.io framework as the current app uses it as well and it's easy to jump to development with it/implement notifications etc. All the features might not be able to doable in expo in long term, so at some point we might need to drop it out. Nobody has strong feelings about keeping it; it's primary use was to ease up getting something out with little effort.

	- Michael's proof of concept something concrete to talk about, to choose tech and decide what to do		* Michael's proof of concept something concrete to talk about, to choose tech and decide what to do

	- Release incomplete beta-release for small scale testing		* Release incomplete beta-release for small scale testing

	- Iterate on this.		* Iterate on this.

	- Consider how would ideal authentication mechanism look like? Previous native mobile app attempted to use cookies in header requests as a simple mechanism. Trustroots uses Passport.js so it might be possible to plug something existing to it easily that's useful for mobile.		* Consider how would ideal authentication mechanism look like? Previous native mobile app attempted to use cookies in header requests as a simple mechanism. Trustroots uses Passport.js so it might be possible to plug something existing to it easily that's useful for mobile.

	- Both Michael and Theo are available to work on this. :-)		* Both Michael and Theo are available to work on this. :-)

	- Nick and Mikael would like not super actively participate in mobile-development, but want to familiarize with it so that they can understand, test, fix, deploy, etc it. This is to ensure longevity of the project by having people who understand little bit about everything around.		* Nick and Mikael would like not super actively participate in mobile-development, but want to familiarize with it so that they can understand, test, fix, deploy, etc it. This is to ensure longevity of the project by having people who understand little bit about everything around.

Nicksellen: Created page with " Who: Michael, Theo, Nick, Mikael When: 2020-05-20 What: React native mobile app; next steps? - Michael would be focusing on writing a react native proof of concept with so..."

2020-05-24T09:07:13Z

Created page with " Who: Michael, Theo, Nick, Mikael When: 2020-05-20 What: React native mobile app; next steps? - Michael would be focusing on writing a react native proof of concept with so..."

New page

Who: Michael, Theo, Nick, Mikael

When: 2020-05-20

What: React native mobile app; next steps?

- Michael would be focusing on writing a react native proof of concept with some basics

- Longer term goal to write Trustroots features in native way in mobile app, vs having them accessible via webview

- For now just write proof of concept with react native, and decide/think about if to use webview later on

- Start in new repository to keep it lightweight, consider in longer term to bring it into `/trustroots` repo to have monorepo approach. Starting in separate repo just is easier and we don't need to deal with any complexity that e.g. dealing with CI setup might bring. Monorepo can be useful way to encourage code-sharing on data-layer level across web & mobile.

- Start with Expo.io framework as the current app uses it as well and it's easy to jump to development with it/implement notifications etc. All the features might not be able to doable in expo in long term, so at some point we might need to drop it out. Nobody has strong feelings about keeping it; it's primary use was to ease up getting something out with little effort.

- Michael's proof of concept something concrete to talk about, to choose tech and decide what to do

- Release incomplete beta-release for small scale testing

- Iterate on this.

- Consider how would ideal authentication mechanism look like? Previous native mobile app attempted to use cookies in header requests as a simple mechanism. Trustroots uses Passport.js so it might be possible to plug something existing to it easily that's useful for mobile.

- Both Michael and Theo are available to work on this. :-)

- Nick and Mikael would like not super actively participate in mobile-development, but want to familiarize with it so that they can understand, test, fix, deploy, etc it. This is to ensure longevity of the project by having people who understand little bit about everything around.