textileio / photos Goto Github PK

Observed after "violent backgrounding and foreground of the app"

Right now, when debugging, reactotron works great when running a sim on ios or android. However, it doesn't connect when debugging on a (connected) physical device. See infinitered/reactotron#272 for a possible fix.

Some work, others have errors, others are stuck in some intermediate state with the upload progress spinning or stalled at some value.

Seems to also be documented here: facebook/react-native#19113

Removing the SVG components from PhotoViewerScreen alleviates the problem. Simple solution would be to conditionally display the icon if on iOS...

Just thinking this through. Seems like we want,

• a share link in every non-default thread
• clicking the link will grab the URL from textile-go
• toss the payload into the native share method and open it for the user

Later on we talked about adding a block to the Thread saying that a public invite was created, we can do that later.

See this a lot when running app in background (maybe offline) mode while taking a lot of photos. The final images don't seem to load very successfully and often have duplicates.

If the node is shutdown from an actual background event triggered by the user, all is well. Probably related to #107, stemming from a background event possibly not being triggered when the app is left to close itself via the screen auto-dimming

if the app crashes while (say) two images are uploading/waiting to upload, then there's never any saga to eventually go back and update those states or those upload pies. Part of the issue in the upload library that we are using. It should really be fixed, or swapped for something more robust.

Currently, our gallery lib attempts to load all the full res images in a given thread at once. For local images, this is pretty quick. But for remote images, this can be quite slow, leading to a less optimal UX. We should consider doing something like:

• show thumb for all
• when on a photo
• load full, and replace

Since the images are only displayed one to a 'page', this shouldn't mess up things for tiling or gallery building.

Would be useful if others can confirm this on their own repos.

Version 0.1(16)

Stacktrace

0x10e955000 + 11507321;TextilePhotos

0x10e955000 + 11501721;TextilePhotos

0x10e955000 + 11514780;TextilePhotos

0x10e955000 + 6270084;TextilePhotos

0x10e955000 + 6277360;TextilePhotos

0x10e955000 + 6281692;TextilePhotos

0x10e955000 + 6266017;TextilePhotos

0x10e955000 + 3310065;TextilePhotos

Reason

SIGSEGV

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/e349e028195964d20c0c74281e3a898c730c768f

I think we need to configure the build environment to use .env.production, but there's nothing specifying that yet.

Version 0.2.4(125)

Stacktrace

main (main.m:14);TextilePhotos

Reason

SIGABRT

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/450c78c228c42bc39b00da8f1c4df52bea0de2e1

Just flagging this as something we should work to improve.

Related to textileio/go-textile#88

Feels like the status of the underlying node should be opaque to the user, especially at startup. We should be able to let the user do stuff while the node is bootstrapping, if / when we have the ability to not block while that's happening... I'm pretty sure that's taking the majority of the time during the initial startup.

Currently in DevicesRedux, the state 'added' is reached as soon as the device is added to the wallet. But we need a step after this where the device is confirmed as being paired, this is later confirmed by a message from the external device saying it received the pair.

@andrewxhill had some ideas on why this is happening, but wanted to log... opened the app, got a few new photos but one of them is from a couple weeks ago.

Version 0.1(17)

Stacktrace

0x1005be000 + 12111156;TextilePhotos

0x1005be000 + 12119080;TextilePhotos

Reason

SIGABRT

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/89caf41a59162cc003147f970b2d8891adbcad08

Version 0.1(17)

Stacktrace

0x1023a4000 + 313180;TextilePhotos

0x1023a4000 + 189524;TextilePhotos

Reason

NSInvalidArgumentException

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/8a756ad06c8f0c8148a7711bfdc30f9319c17a17

We do this in the go CLI, may as well let it handle mobile thumbs too since we're just using a JPG version

Version 0.2.6(39)

Stacktrace

runtime.raisebadsignal + 108;TextilePhotos

runtime.raisebadsignal + 72;TextilePhotos

main (main.m:14);TextilePhotos

Reason

SIGSEGV

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/d093e001977bf22e073590837124d30dc13b91ba

I'm seeing an extra image load from the Node in the ProgressiveImage component. It seems that the TextileImage that loads the thumb switches it's 'path' prop from thumb to photo. I don't think that's necessary because there's a separate TextileImage that loads the photo path.

After latest update to Go layer, all the wires aren't connected correctly. Working on the update now.

WIP in #160

Version 0.1(12)

Stacktrace

0x1042f8000 + 315216;TextilePhotos

0x1042f8000 + 191560;TextilePhotos

0x1042f8000 + 939340;TextilePhotos

0x1042f8000 + 938336;TextilePhotos

Reason

RCTFatalException: Unhandled JS Exception: ReferenceError: Can't find variable: Evilicon

This error is located at:
in t
in RCTScrollContentView
in RCTScrollView
in ScrollView
in t
in t
in RCTView
in n
in Connect(n)
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in t
in withCachedChildNavigation(t)
in Unknown
in n
in n
in RCTView
in t
in Connect(t)
in e
in n
in t
in RCTView
in RCTView
in t

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/31d4db56228aa399d20aae7298c0a113f81c9c6c

photoTask will queue up all photos to add before they are marked as added

if photoTask is called a second time before that happens, the photo will be added a second time no problem

Currently, prob due to no peers I see an error come back when accepting a thread invite,

2018-07-16 14:50:56.387 [info][tid:com.facebook.react.JavaScript] 'error', { error: 
   { [Error: failed to get block for QmTdt36G6RXktJ9UypUftiqGdogidNBmxwwNcHW39Jg3WB: context deadline exceeded]
     framesToPop: 1,
     code: '1',
     nativeStackIOS: 
      [ '0   TextilePhotos                       0x00000001032d4616 RCTJSErrorFromCodeMessageAndNSError + 134',
        '1   TextilePhotos                       0x0000000103263183 __41-[RCTModuleMethod processMethodSignature]_block_invoke_2.218 + 179',
        '2   TextilePhotos                       0x00000001031493a2 -[TextileNode acceptExternalThreadInvite:resolver:rejecter:] + 370',
        '3   CoreFoundation                      0x000000010a266ccc __invoking___ + 140',
        '4   CoreFoundation                      0x000000010a266b84 -[NSInvocation invoke] + 308',
        '5   CoreFoundation                      0x000000010a27f8d6 -[NSInvocation invokeWithTarget:] + 54',
        '6   TextilePhotos                       0x000000010326518c -[RCTModuleMethod invokeWithBridge:module:arguments:] + 2796',
        '7   TextilePhotos                       0x000000010331ac02 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 786',
        '8   TextilePhotos                       0x000000010331a72f _ZZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEiENK3$_0clEv + 127',
        '9   TextilePhotos                       0x000000010331a6a9 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 25',
        '10  libdispatch.dylib                   0x000000010cc2e807 _dispatch_call_block_and_release + 12',
        '11  libdispatch.dylib                   0x000000010cc2f848 _dispatch_client_callout + 8',
        '12  libdispatch.dylib                   0x000000010cc37c41 _dispatch_queue_serial_drain + 1305',
        '13  libdispatch.dylib                   0x000000010cc38556 _dispatch_queue_invoke + 328',
        '14  libdispatch.dylib                   0x000000010cc343a0 _dispatch_queue_override_invoke + 726',
        '15  libdispatch.dylib                   0x000000010cc3b3c8 _dispatch_root_queue_drain + 664',
        '16  libdispatch.dylib                   0x000000010cc3b0d2 _dispatch_worker_thread3 + 132',
        '17  libsystem_pthread.dylib             0x000000010d159169 _pthread_wqthread + 1387',
        '18  libsystem_pthread.dylib             0x000000010d158be9 start_wqthread + 13' ],
     userInfo: { NSLocalizedDescription: 'failed to get block for QmTdt36G6RXktJ9UypUftiqGdogidNBmxwwNcHW39Jg3WB: context deadline exceeded' },
     domain: 'go',
     line: 2111,
     column: 26,
     sourceURL: 'http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false' } }

We'll need to do something with those errors

When you tap on the '!', the toast pops up with no message.

Tapping on a white thumb loads the full photo just fine. So, node is running but possibly not finding the thumb content right away... ? Needs investigating...

While #46 addresses node life cycle issues during the normal functioning of the app, it does not address the RN reload issue in the simulator. Thought I had fixed that, but no. The deal is that there's no "hook" to shutdown the node with (that i could find / know of)... and we seem to lose a reference to the existing go layer mobile node instance. So, a new one is created for each reload. You'll see some wonkiness in that the thumbs just show up white, but a lot more badness is happening under the hood.

When upgrading from (probably) the app store version of the app, to what we're working on for thread invites, the app tries adding all sorts of old photos, probably all old photos. Need to look into this and see if there's a migration issue.

We need to let the user know that

• Data is shared through a protocol that makes copies of that data potentially impossible to delete.
• Data is visible to all members of the shared channel and any one of them can download that data.
• What types of meta data will be shared.

It would be nice to have a pop-out kind of second onboarding experience where we can walk them through the steps.

Using the timestamp as the getPhotos cursor allows downloaded/edited photos to sometimes mess up all uploading or not be uploaded themselves.

Needs a photo uuid based parsing of new photos

Currently the state is shown in the placeholder text that is removed when there are photos in the grid.

Right now, the number of grid columns (3) is fixed. This looks strange when the device is rotated. We should compute the optimal column count and update this dynamically when the phone is rotated.

currently they work but are converted to some static form, guessing jpg

I flow the install steps , but get this "mobile.Mobile" module dose not exist ? what is wrong ?

/Users/chaim/Downloads/textile-mobile-master/android/app/src/main/java/com/textilephotos/textileipfs/TextileIPFSModule.java:14: error: module mobile dose not exist.
import mobile.Mobile;
^
/Users/chaim/Downloads/textile-mobile-master/android/app/src/main/java/com/textilephotos/textileipfs/TextileIPFSModule.java:15: error: module mobile dose not exist.
import mobile.Node;
^
/Users/chaim/Downloads/textile-mobile-master/android/app/src/main/java/com/textilephotos/textileipfs/TextileIPFSModule.java:23: error: can not find symbol
private static Node textile = null;
^
symbol: class Node
location : class TextileIPFSModule
/Users/chaim/Downloads/textile-mobile-master/android/app/src/main/java/com/textilephotos/textileipfs/TextileIPFSModule.java:51:error: can not find symbol
textile = Mobile.newTextile(dataDir, apiHost);
^
symbol : var Mobile
location : class TextileIPFSModule
4 个 errors
:app:compileDebugJavaWithJavac FAILED

Version 0.2(117)

Stacktrace

Reason

RCTFatalException: Unhandled JS Exception: TypeError: undefined is not an object (evaluating 'e.meta.username')

This error is located at:
in t
in Connect(t)
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in Connect(t)
in t
in t
in withCachedChildNavigation(t)
in Unknown
in n
in n
in RCTView
in t
in Connect(t)
in e
in n
in t
in RCTView
in RCTView
in t

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/2f6356156dc61671770c014bb718bdb49c98200c

Something in the form of,

https://www.textile.photos/invites/new#invite=QmXqvHnHHak9eMqRp1ERdDNbNBJQjtjybpgcGgPzJ5q8f4&key=17Ubjv0vfXLeJTmpidk17UbjtmEuyKyiNGMgpLceTWNa&name=coo&from=andrewxhill

specifically, the node wont take care of the URL, path, or the creation of the from parameter

@asutula I think you had some update on this, but I can't remember what it was and didn't see an issue for it. Still seeing them from time to time.

Version 0.1(42)

Stacktrace

Reason

RCTFatalException: Unhandled JS Exception: Invariant Violation: Objects are not valid as a React child (found: object with keys {domain, message, code}).

This error is located at:
in RCTText
in Text
in RCTView
in n
in RCTView
in e
in RCTView
in n
in Connect(n)
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in t
in withCachedChildNavigation(t)
in Unknown
in n
in n
in RCTView
in t
in Connect(t)
in e
in n
in t
in RCTView
in RCTView
in t

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/306da0fc4b1e15df53af5b88b723384b217a0620

Currently just passes through to success. Need to look at what errors happen here,

https://github.com/textileio/textile-mobile/pull/148/files#diff-e5eeead3c8fd48e9ba45bdcc42dc0f68R22

Since we rely on AppState to manage the IPFS node and photo querying logic, we need to have a consistent API to work from. Need to investigate exactly what the inconsistency is and fine a work around.

This would require code changes (the API from 1 -> 2 has changed), but comes with benefits such as better support for more recent react-native versions.

Its time to start formal unit/integration testing. React Native provides pretty good Jest-based testing facilities, including auto-mocking modules etc. There are also some examples for mocking custom NativeModules.

Here is a failing password,

%&6fkuJQJBOuEaZlH5yFj&EUFgyp#y66!G7cj4dwHv

What I've been able to see:

• it only happens if the string is in the password field. dropping the string into other fields wont crash the app.
• moving the focus out of the password field (click on another field) will crash the app (submit not required)
• each of the special characters in the failing password seem to work as part of a shorter password
• a longer password without those special characters also seems to work
• not storing the password in the state will avoid the crash, but will render the form empty so it's pointless. the idea there is that merely entering the password in the form field is not enough to crash it.

Version 0.1(44)

Stacktrace

Reason

RCTFatalException: Unhandled JS Exception: Invariant Violation: Objects are not valid as a React child (found: object with keys {domain, message, code}).

This error is located at:
in RCTText
in Text
in RCTView
in n
in RCTView
in e
in RCTView
in a
in Connect(a)
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in RCTView
in n
in t
in n
in RCTView
in RCTView
in t
in RCTView
in e
in r
in Unknown
in n
in n
in t
in t
in withCachedChildNavigation(t)
in Unknown
in n
in n
in RCTView
in t
in Connect(t)
in e
in n
in t
in RCTView
in RCTView
in t

Link to App Center

• https://appcenter.ms/users/andrewxhill/apps/Textile-Photos/crashes/groups/63acd00cc4c9cc1574870e21ead1630e5166535c