New methods for eSIM ph2

[amegias]

Due to this spec, we need to expose several methods through the bridge:

Get device model

getDeviceModel: () => Promise<{model: string}>

Request → {type: "MODEL", id: string} 
Response → {type: "MODEL", id: string, payload: {model: string}} 

It will return a model like SAMSUNG-SM-G930A, iPhone9,3, ...

See:

• https://developer.android.com/reference/android/os/Build#MODEL
• https://www.innerfence.com/howto/apple-ios-devices-dates-versions-instruction-sets

Get Esim Info

getEsimInfo: () => Promise<{supportsEsim: boolean, eid: string | null}>;

Request → {type: "GET_ESIM_INFO", id} 
Response → {type: "GET_ESIM_INFO", id, payload: {supportsEsim: false, eid?: "1234"}} 

eid is optional and only available in Android

Request Device IMEI

implement the following method (already existing in the bridge) only for Android

requestDeviceImei: () => Promise<{imei: string | null}>

Request → {type: "IMEI", id} 
Response → {type: "IMEI", id, payload: {imei?: "1234"}} 

Deprecations

Mark as deprecated in webview-bridge

• requestSimIcc
• requestSimImsi

[nimeacuerdo]

MODEL method in Android is already implemented and returns https://developer.android.com/reference/android/os/Build#MODEL

[amegias]

MODEL method in Android is already implemented and returns https://developer.android.com/reference/android/os/Build#MODEL

Then, could you specify the method here please? Just to know the name, payload, result, etc and implement it in iOS

[pladaria]

I would name this method as getDeviceModel: () => Promise<{model: string}>

@amegias according to the (now deprecated) document

Request → {type: "MODEL", id} 
Response → {type: "MODEL", id, payload: {model: "One Touch Easy"}} 

@nimeacuerdo please, confirm that Android implementation follows this description

[nimeacuerdo]

I would name this method as getDeviceModel: () => Promise<{model: string}>

@amegias according to the (now deprecated) document

Request → {type: "MODEL", id} 
Response → {type: "MODEL", id, payload: {model: "One Touch Easy"}} 

@nimeacuerdo please, confirm that Android implementation follows this description

Yes, that's what we have in Android right now.

[nimeacuerdo]

@pladaria what about this for the other two methods?

getDeviceImei: () => Promise<{imei: string}>
Request → {type: "IMEI", id} 
Response → {type: "IMEI", id, payload: {imei: "1234"}} 

getDeviceEid: () => Promise<{eid: string}>
Request → {type: "EID", id} 
Response → {type: "EID", id, payload: {eid: "1234"}} 

[pladaria]

@nimeacuerdo

the webview bridge already has a requestDeviceImei method using the IMEI message type.

https://github.com/Telefonica/webview-bridge/blob/master/src/device.ts#L15

Device/SIM related methods already implemented by the webview bridge are:

• requestSimIcc: (type SIM_ICC) 0 usages in webapp
• requestSimImsi: (type IMSI) 0 usages in webapp
• requestDeviceImei: (type IMEI) 0 usages in webapp
• getEsimInfo (type GET_ESIM_INFO): 1 usage in webapp: https://github.com/Telefonica/webapp/blob/master/web/src/common/webview/native-utils.tsx#L188

Does it make sense to return an eid property in the getEsimInfo response? It currently returns {supportsEsim: boolean} Should we deprecate all unused methods? which ones are already implemented in iOS/Android?

[nimeacuerdo]

Only GET_ESIM_INFO is currently implemented on Android.

Regarding eid, it is pretty specific to eSIM so it could make sense to add it to the existing getEsimInfo response as additional data.

[amegias]

Only GET_ESIM_INFO is currently implemented on Android.

Regarding eid, it is pretty specific to eSIM so it could make sense to add it to the existing getEsimInfo response as additional data.

but the field must be optional since iOS won't send it. No problems from the iOS side.

Could you edit my first comment with the proposal @nimeacuerdo ?

[nimeacuerdo]

Only GET_ESIM_INFO is currently implemented on Android. Regarding eid, it is pretty specific to eSIM so it could make sense to add it to the existing getEsimInfo response as additional data.

but the field must be optional since iOS won't send it. No problems from the iOS side.

Could you edit my first comment with the proposal @nimeacuerdo ?

Done, let me know if it's ok for everyone @pladaria @amegias

Also, IMSI and SIM_ICC could be removed given they are not implemented nor needed in Vivo eSim flows