artsy / mobile Goto Github PK

• Doesn’t work in sim
• Entering URL in address bar of Safari won’t work, which makes sense, needs to be clicked (also in web pages loaded in Safari?)
• https://limitless-sierra-4673.herokuapp.com provides better validation than apple’s tool (check if uploading an IPA also checks entitlements and all domains)
• was adding entitlements file to the bundle needed or not? Nope
• Native (iOS) to Web (Mac Safari) Handoff: User activities must be made current from viewDidAppear and invalidated from viewDidDisappear. Making them current from viewDidLoad (so presumably when the VC is not in the responder chain yet) does not work.
• Web (Mac Safari) to Native (iOS) Handoff: broken on iOS 9.0.x. Test on iOS 8.x or iOS 9.1 beta.
• App Search Deep Link documentation makes it seem like App Links/Twitter Cards are a viable alternative or Smart Banners, supposedly also to have Universal Links work. This is not the case and you won’t find out until you run the validation tool: “Universal Links are not supported on Facebook App Links/Twitter Cards. Please use Custom URL Schemas.”
• (the docs do mention this, I think ?, but add nonetheless) The app site config file is only downloaded the first time after installing an app, so make sure to remove the app and re-install for testing changes to the config file

We should do beers, or lunch, or something.

Judging by our conversations with Facebook, it doesn't sound like one of the big selling features of ReactNative is to share code between Android and iOS, as was our hope. Worth continuing to investigate, but in the mean time, I have some thoughts about breaking our apps into smaller pieces so at the very least, we can share code between eigen/energy/eidolon.

So this is what I'm thinking:

We have different pods for different view controllers. They are well tested. They abstract things away. In apps, like eigen, energy, and eidolon, you subclass them and get a bunch of stuff for free. They'd live in their own pods – open source, but not on Trunk.

OK, so that we can all agree on. What about the architecture of these (abstract-ish) view controllers?

• I'd like them to provide protocols that their model objects conform to.
• I'd like them to use MVVM to provide support for common actions. For example, getting artwork details or whatever. I like MVVM because it'll keep the view controllers light and provide a way for individual apps to customize/extend behaviour (by subclassing the view models).
• I'd like them to rely on a centralized auth method.
• I'd like them to avoid referring to self.view if possible, to avoid loading the view hierarchy unintentionally.
• I'd like them to work with a common routing strategy.
• I'd like them to use ReactiveCocoa. Hear me out:
  • I honestly believe that signals represent a fantastic abstraction for network calls. They're lazily loaded, support cancellation, there's AFNetworking support, and provide a good "I got data, I finished, I errored" semantics.
  • View controllers would use ReactiveCocoa with their view models to expose signals that can be used with bindings by the view controller subclasses.
  • Additionally, they would expose methods to do the same work, but with callback blocks. That way projects aren't forced to do things "the reactive way." For example, something really basic like:

- (void)whatever:(void (^)(NSArray *whatevs))callback
    [self.signal subscribeNext:^(id x) {
        if (callback) {
            callback(x);
        }
    }];
}

Or whatever we need (error handling, etc). It would be awesome to find a way to make writing the "subscribe to a signal and return whatever is next" sorts of methods easy/fast. Maybe a C macro? Or auto-generated code? Dunno.

Next steps would be pulling small, similar view controllers out of both eigen and energy to see how much overlap there is. Do this a few times and we'll have an idea of how much effort this would be, the potential benefits of doing this, and a rough timeline of steps.

What have we programmed ourselves away from, ideas:

• NSNotificationCenter as a coupling method
• Moving towards functional on the micro, OOP on the macro
  • Old Energy Sync
• Manual Testing?
• Internal Navigation Controllers?
• Inline Analytics? ( though maybe analytics at a high level is a topic on its own )
• Deeper inheritance over class composition
  • Model objects for view controller communication
  • Network models
• A move away from singletons hidden behind class methods
• Migrate from class based APIS
• Responder Chain ( e.g. the ArtworkVC button stuff ) ?

Hello Artsy Mobile team!

There are a large number of workflows for managing and releasing an app:

over @paperlesspost, we use a "feature branching" model:

• Create a new branch from master
• Do your feature or bug/other development
• When finished get code review from team members
• Once all CR is addressed and signed off on, mark the branch as "ready for QA".
• QA takes a pass and either accepts or rejects it. If accepted it goes to "master". If rejected, it goes back to development.
• At the end of our "sprint", we cut a release branch, "soak it" and QA it for a few days to a week, then eventually submit that branch to the App Store.

I've spoken with a dev from Pinterest who stated a similar workflow, and as of ~2 years ago, Facebook iOS followed a similar model (not sure if they still are).

I've more recently been enlightened to learn about "Git Flow", which we are beginning to trial-run right now. (http://nvie.com/posts/a-successful-git-branching-model/)
It encourages devs to ship smaller branches to the "integration" (or "development") branch after receiving CR, and having nightly builds of that branch be QA'd. This all ties into CI automation of tests, as well as developing new feature behind "feature toggles". It also changes how QA functions, having them test nightly builds, rather than "feature branch" builds

There are some other topics related such as:

• How is code review managed?
• How much automation do you have
• How do you plan out releases/features?
• Do you have product manager, what do they use to help plan releases?
• How does QA tie into your workflow?

I know you have written in the past about Arty's 4(?) week release cycle (not having luck finding it right now if you could cross post!)
I've also read up on an earlier post: https://artsy.github.io/blog/2012/01/29/how-art-dot-sy-uses-github-to-build-art-dot-sy/
and could see this as a part-2 elaborating on it.

What is Arty's workflow for successfully developing and shipping apps?

Thanks as always for working in the open! Incredibly helpful resource for learning

We currently have 2 separate versions of View In Room, with different features.

• One supports iPad only and does multiple zoom levels.
• The other is iPhone only and supports parallax and walls and the random dude.

Now all our apps are iOS8+ we can use SceneKit to generate a view in room, room.

Outline

I made a quick prototype of this as a mac app in swift

download

But going from that, to

is a tricky job. It's a bit easier building it initially as a separate mac app because it's faster to iterate and we have more input devices to work with.

Background

Our VIR assets have always been done in 3d and then we've worked with the rendered outputs, so it might be possible to get some of the original assets. I'll ask @robertlenne.

Advantages

• We can consolidate the code bases among two shipped apps, and makes it much easier for eidolon integration if wanted.
• Experiment in a Pod View Controller
• Finally get some consistency between iPad + iPhone versions ( Eigen, for example doesn't support VIR )
• Improve the animation between an artwork and VIR
• Removes the uncanny valley around our parallax implementation
• It will save many megabytes of initial download time on our apps.

It's really cool and we should talk about it.

As per #52

• Support pods that can register their own selection of routes, so that we can say move all of fairs, or auctions into their own pod.
• Support updating routes so we can do echo stuff
• Returns a view controller
• Params dict as a way of sending objects through
• Support /x/:id routes
• Support scoped routing?

JLRoutes does nearly everything here, but that it returns a BOOL rather than returning a VC. Could look into making a fork that does this, then see what Joel thinks.

@ashfurrow:

@orta I was thinking in a blog post, you could talk about how instead of polishing it for open source in secret, before opening it, you only removed keys and would instead work on making it open source-friendly _

@orta:

we have to move to do github style PRs
orta [12:18] of same branch repos, I think to get working CI

Options:

• TeamCity - https://twitter.com/orta/status/568788102745079808
  • - https://github.com/foreflight/foreflight_build_agent

The Artsy mobile team is pretty good with remote workers, but we could definitely be better. There are some recent improvements to things in the office space – which are awesome – but need to be matched with corresponding changes with team culture.

Talking with the Squarespace team today, they had some really cool ideas. Things like:

• Having an open Skype call between team members (with themselves muted) to lower the barrier to communicating and feeling connected
• Having regular demo meetings. These are hour-long meetings for the mobile team where someone talks for 30 minutes about something they're doing and then a 30 minute discussion. Ideas for us could be @katarinabatina talking about the design language she's using in some new designs, @alloy's work on local server response caching, or @1aurabrown's work on CI issues.

I asked about the biggest problem they faced, and unsurprisingly it was information dissemination. How can we make it easier to relay the sort of in-person conversations that happen in the elevator to remote workers? How can we simulate those types of interactions with remote peeps? Not only are they missing out on that stuff, but we're missing out on more meaningful connections with them.

So: anyone have ideas? Suggestions?

We use a heuristic to determine if the project is being built by a staff member (or CI) who has access to our private fonts pod. Orta has suggested we move to an environment variable.

• Eigen
• Energy
• Eidolon

We'd need to update Potential as well.

If we wanted to move a View Controller from Eigen, or to offer limited versions in one app but not another we would need a way to separate out the dependency graph.

• What does this look like?
• How should they react?
• How can then interact with other Pod-like VCs?
• What about additional contexts?
• Model objects as protocols?

Assigned to @ashfurrow for investigation

Hi all,

Given that @alloy works remotely, @1aurabrown is in and out due to jury duty, and both @ashfurrow and @orta are devoted speakers on behalf of the team, it would be great if we could start to schedule things more "visually" so me and the rest of the team have more of an idea when people are online and available versus working on a talk, out of town for a talk, workin' on the house boat, etc. Scheduling things in advance will also help us to understand how much we can get done on a particular sprint.

Using the team OOO calendar should also be something we feel free to use but Orta suggested that a specific mobile team calendar may be helpful. Thoughts?

What considerations are made, test coverage, community support, pretty README, code quality etc.

Deadline is this Friday.

URL for gdocs: https://docs.google.com/document/d/1XCeRU3f4HaBHb7eQcc4MSDVZc-5k5CtwyXpAuQepGNs/edit

We've thrown in most of the structure, and filled out a lot of the paragraphs. Most of the work revolves around hooking things together and polish.

Something that can build off Dave's - dbgrandi/dbgrandi.github.io#8

I've been giving a bunch of talks to hack schools with a lot of low-level pragmatic advice around both contributing to OSS and getting your first job and doing well in it. Can build off that.

@artsy/mobile

After talking with @orta and @katarinabatina over the past months, it’s becoming more and more clear to me that the current approach of trying to essentially replicate the Artsy platform in a native application doesn’t scale very well.

We’re often just playing catch-up with changes on the web apps and because we’re dealing with native code, these changes often take more time to implement than on the web. This means that there’s little time to actually work on awesome features for our users that would only be possible in a native app.

Besides that is also the issue that the web app can be updated and deployed immediately, whereas the native app has to deal with the App Store review time, making this an even more painful experience.

My suggestion is the following:

• We create a completely new Eigen app that is a very lean application:
  • it basically shows martsy views for all of its content
  • only features that benefit from native integration are implemented natively, e.g.:
    • bottom tab bar
    • navigation stack and transition animations
    • sharing content (social, email, text message, etc)
    • search controller
    • push notification handling
    • VIR, although I think this should be very doable in HTML/CSS and thus also be available on martsy
  • we use state-of-the-art WebKit APIs to integrate the web and native components. E.g. on iOS we should now have access to all the WebKit APIs and so we should be able to advanced DOM integration work.
• We port that new Eigen app to Android, which should be much less work to do initially and to maintain.
• martsy might need to be more optimised to work on mobile devices of more sizes, e.g. iPad, because force’s browser paradigm often doesn’t feel right when embedded into a native app imo. (E.g. the extra navigation bars that some pages have, such as those of a fair.)

Pros:

• Most design changes and/or content fixes will be available immediately as they are deployed to the web.
• When we start localising content, we only need to do that in one place, namely on the web (which benefits all users). Any content that needs to be localised in the apps will be very minimal.
• No need to duplicate other efforts, such as analytics.
• We have spare time 🍸 🎉 to spend on smaller targeted truly native apps that target iOS and Android, possibly implemented in something like React Native, for e.g. fair specific apps, collector apps, etc, as @katarinabatina and @orta were already discussing.

Cons:

• Native feel may decline, but as our UI already doesn’t have that pure iOS native feel, I think this can be kept to a minimum.
  • I do think that our mobile expertise should be taken into account when designing/implementing the martsy views, to ensure those behave as native as possible.
  • I think it would make sense to invest in a CSS3 expert that would be able to give a native-like (e.g. animated) feel to the UI. Or do we already have someone for that?
• A lot of ‘wasted’ effort on the existing code-base. That’s an emotional issue, which I can totally sympathise with 😓

When searching in Eigen, I see unpublished profiles exposed in search. Clicking on one of the profiles leads to a 404 page.

@alloy can improve:

• Whitelist resources that are allowed to go stale. Never cache auctions!
• Determine network connection quality:
  api/v1 system ping + 80ms
• keep metrics, such as request time, with each cached ‘object’ so that we can then test against that later on and decide what is acceptable or otherwise determine that serving stale data is allowed.

We should do beers / lunch / something

Rack for Testing, using XPC to communicate between each part of the system.

With the MVP goal to be able to run a test harness inside a hosted app and to be able to pass tests in via XPC to be ran without restarting the sim.

Ideally can split into three parts [ UI ] <---> [ Test Compiler ] <---> [Test Runner ]

Wherein the same UI could exist for many types of languages and test compilers, runners don't have to be some async running process. Could just be the same thing ran instantly but provides a separation against crashes etc.

Initially letting @modocache take a stab at this, but we can take a shot anytime @alloy feels he has some space. Assigning to him, as it is would be largely his work I expect.

http://castparty.org

I'm thinking this would be a good show, if you're all into that?

Use ARModernEmailArtworkViewController as an example of migrating towards more maintainable code via class composition via:

• ARModernEmailArtworksViewControllerDataSource
• AREmailComposer
• AREmailSettings

So, you'd write a DSL which is given a few ivars e.g: lines_of_code, pr_url, number_of_commits, files_modified, files_added, files_removed

Culturefile:

if (lines_of_code > 20) && (files_modified.includes? "CHANGELING.yml" == false) {
    fail "needs to have a changelog note for large changes"
}

if (files_added.length > 2) && (files_modified.includes? "ARAppDelegate+Analytics" == false)  {
    warn "You may want analytics"
}

I though this was a nice idea, https://twitter.com/andy_matuschak/status/535860039391539201

We should do something like this. Any thoughts? It has to have tea. You're not allowed green tea. Or Coffee, cause that's not tea. Tea.

I’ll be at the NYC office from April the 14th, we should definitely discuss:

• The networking abstractions in Eigen: artsy/eigen#277 (comment)
• Get our certs and provisioning profiles figured out for once and for all, for all apps and beta/App Store versions: artsy/eigen#291
• Auction data being up-to-date is probably very important, as such polling and notifications can be unreliable sources. Discuss alternatives such as web-sockets.
• Discuss with @dblock about a possibility to have a shared JSON payload test suite that is verified against the API and can be used in other apps (Eigen) as test fixtures and for self-documenting purposes rather than reversing what the web front-ends do.
• Discuss with e.g. @dblock about caching/preloading of at least fair content but probably also content such as /magazine and /shows:
  • All (?) API calls have a max-age of 0, so the `NSURLCache behaviour is to never consider the cached data.
  • We can force always use the cache (such as the ‘offline mode’ option that AFCache has), but then the question is how/when to update stale cached content.
  • Currently I enable ‘offline mode’ of AFCache when the device has no network connection at all.
  • But ideally we would also defer to the cache if the connection is ‘slow’, the question is ‘what constitutes slow’?
• Talk with @orta about a custom Xcode test runner/reporter plugin and possible other features such as auto-run changed tests.
• Discuss with @orta the idea of splitting eigen into a collection of smaller individual mini-app-like frameworks, ala Force / Ezel
• Transitions of Language

Once we, you know, do them.

• Eigen
• Energy
• Eidolon

What is it, in our opinion?

We should have a minimum vacation policy in 2015. See here for relative details.

This can probably work by us encouraging each other to take time off, until we know they've hit the minimum. Which should be the same as a cool enlightened country like Denmark. I wanna go live there some time.

We want to put some time in before making any larger technology decisions.

Discussed today and we think it makes sense for @1aurabrown and @sarahweir to devote week 6 time this sprint to tackling an aspect of eigen in React Native. May 25th - May 29th. @1aurabrown should do some research, and run through some tutorials beforehand too.

Giving myself a due date - will have something up by Friday

dooooooooo ittttttttttt

This is a happiness enhancement for me.

Doesn't have to be OSS, but I think this lowers the barrier to making little hack projects.

You should seriously consider hiring remote developers; let's say; I don't know, from Costa Rica maybe…

I know that we went into it at "Artsy Mobile's Culture" but that doesn't go into bundler, fastlane, pods etc etc.

https://iphone.artsy.net

• New repo, we could do the opposite to https://github.com/artsy/force-public, wherein we make our current repo private and use that for time-sensitive, or confidential PRs that need to be private but that we create a new repo ( with maybe even a new history? We'd have to probably crop the history for the private one too, they will leak into public for sure. ) that's public and we migrate over issues / milestones / CI to the public repo and use that from then on in.
• Existing Repo, read + sanitise all 2k issues, delete PRs leaking information, nuke git history for any file that's ever had a key in it, kill git history and open the current repo. Still create an eigen-private that we can use when something shouldn't be discussed publicly for whatever reason.

Expectations vs reality, sore spots, easy wins, ways to avoid hard times migrating to Swift 2.1, reasons why to/to not migrate now, lessons learnt.

I noticed that on the eidolon project the pull requests go in the form of:

@[person name]=> [Actual title]

Is this a form of: "hey, I made this PR, please review it"?

Sometime. Soonish. /cc @sarahscott