Things to discuss IRL about mobile HOT 21 CLOSED

ED: React is like creating components which definte their own ways of getting 
ED: Our Caching can come locally. Probably similar on android.

SS : can we get metadata before?
OT: API v2 allows us to ask for things we want as a singular request
ED: Its kinda how it works now, API is built for website

AF: I like the network model appraoch, easy to test
AF: it takes all of the network activity out of the object
    it handles all information about the fair - it does the transference of 

OT: Let's kill promise based networking
    Replace with KVO + network models

AF: All deps will still need to  work
AF: but do we need to have the equivilent for android?

OT: 
  android shouldn't be a raw factor as the decision but a part
  we should continue for best for ios app we have
  We can steal people
  we become more valuable in artsy
  write more complicated apps
  we can make better things with 

OT: Test Laura + Sarah W could work on a settings VC as a test bed to get a sense of what

ED: I think it'd be sad to get to a state where we have to implement things twice
  : would be nicer to switch inbetween the teams ourselves
  : instead of you do x, and you do y.
  : I consider myself an engineer, not an ios one

Q for react-ers: Localisation
   How to transition
   How to take an existing View Controller and turn it into react native

OT: Polling for martsy?
ED: dB opened a ticket
OT: ask about amking a pollign contract that we can start and stop via js

OT: Testing, I don't believe Xcode will improve in WWDC
ED: we could build a Mac app, lists test, talks via XPC

AF: A way that works similar to Reveal via sockets, can try build something on specta/quick
ED: thats how OCTest works
OT: MVP is test file re-running on an XCTest thing

BG: 
  initially had no interest in a mac app
  wanna build x
  to figure out what I want is to build it

ED: 
  I have ideas around how this can work 
  the extension _is the test_

ED: the bundles isn't possible
  XPC + extensions is the same kind of architecture
  same idea, separate processes

BG: The issue of opening your sim?

ED: You dont ened to re-launch 
  : Sock Puppet app keeps running, spins extension

ED:
  Host app extension that spawns the extension
  no luaunch
  wouldnt work on a device

BG: I dont understad why it does any why it doesnt 
ED: It does not work
    Mac app is just a front
BG: Interested in writing the runner so people can launch an app and run an extension

BG: 
  Want to reverse engineer the underlying infrastructure
  that part is pretty tangential

ED: 
  Sim is unreliable, restart sim, restart xcode. The bridge is fragile.
  once the ism is done, it keeps running
  a relaunch is a lot of the wait

BG: 
  A better testing solution
  the hardest part is like "global state, inserting the right invocations"
  a better runner fixes that

ED: 
  Bacon is still my fav
  isnt the other problem with current infrastructure

ED: 
  a lot of simpler frameworks just raise an exception at the stio at one test failure in a single test
  think xctest has to keep 

BG: 
  `beforeAll/afterAll` run before suite 

ED: so how do you run one?
BG: 
  each block has a reporter object, that way you can get really flexible. Can message the reporter anything. Can do things like skip, pass through, and they can talk to each other
  alternatively a closure returns waht happens
  reporer can raise or fail


ED: runner starts, then framework can report it out
BD: its a function that takes objects as
    test runner should be as explicit as possible
    in objc that would be a macro
    make it a class, whatever

ED: test runner is a separate tool
    is it a separate runner, that runs

BD: my plan, is it goes to a main mainfunction 
ED: build it with specta/quick whatever
ED: lets say mac app
    it does  dry run
    results are relayed back
    how does that work?
    if the runner is a tool

ED: I did a macbacon that sent things via XPC
BG: assume I know nothing
ED: you make a runner, it exposes an XPC API that says
    give me a list of tests, the list of objects + closures
    it would expose an API for showing the API
    on every fail it send it back over XPC
    tests keep running and you can kill
    kill it the xpc process
    then it has a test runner has a focused test API
      "now only run this one" 
    as separate process
    this is what xcode is trying to do as xcode
    frontend needs to know state, other thing needs to say "now its time"
    but that reporting needs to be possible

BG: 
  rpsec runs pending examples and says if it crashes then it's ruby not your code
  junit does rules for whether a test takes 
  unwrapping options "assert this isnt nil"
  shouldnt out an if in your tests
  "clown town"

ED: 
  I want to be able to build really simple frameworks on top of there\
  needs to be a simple interface for xcode

BD: 
  I think theres things I dont get around the testing code

ED: 
  assume this thing is running, it is an app, a process. That only says" please give me code to run"
  sim is a mac on the app, has full test
  test gets build into an xpc bundle, which is also somewhere on the hard drive
  the test runner would generate the bundle on the harddrive
  and it would xpc and send something to the sim 
  runner would invoke the "artsy invocation thingy"
  it would signal
    create the bundle
    the sim app would take the bundle
    and then run the xpc stuff
    running the code 
    then send the signal back

  it would take more time than just running a closure
  bt its more efficient by far
  has a runner that just evokes the focused test
  can be optimised by keeping it running

  thats what I was trying to make sense of "is it time for us to build our own"
  not a far of building a pluigin


AF: you can send it a fake sim, to open, then do the right one the second time generally
So basically we xcrun Instruments with a named simulator, expecting it to fail because we don't inlcude an instrument to run, but the simulator is now launched and ready to be invoked by actual tools. See: https://github.com/artsy/eidolon/blob/8ca8ed0d19e68e5b62a524b594f0a8797bb41029/.travis.yml#L10


BD: 
  there is a world where the runner is the host could do anything

OT:  the runner could be a mac thing like rack
BD: the XPC thing can be everywhere
ED: Rack is a spec for how to nest applications
     we're doing something similar, because everything is so abstract
    you can build it as you see fit for the problem at hand,  so we can have different types of test runners depending on levels of difficulty
    I can see a thing that is this side is just reporting