philipp.hofmann
-
Content Count
66 -
Joined
-
Last visited
Posts posted by philipp.hofmann
-
-
The question for me is now, why it works with your MacOS Big Sur? Is it a different setting for the Mac or a different setting in the provision profile?
Can you see that the method
TTetheringNetworkManagerCommunicationThread.DoOnReceiveDatareached if you start the app on MacOS, equal if DesktopWWallApp or MobilePhotoApp?
-
Hi,
even after adding the new Apple Multicast-Entitlement it's not possible to use Tethering with MacOS 11.x and iOS 14.x devices on server side. This devices will not be found with the method
TTetheringManager.DiscoverManagers
requested on client side.It's fine with MacOS 10.x and iOS 13.x devices on server side.
You can test this also with the samples
- DesktopWallApp (server)
- MobilePhotoApp (client)DesktopWallApp Windows Android MacOS 10.x iOS 13.x MacOS 11.x iOS 14.x MobilePhotoApp Windows OK OK OK OK not OK not OK Android OK OK OK OK not OK not OK MacOS 10.x OK OK OK OK not OK not OK iOS 13.x OK OK OK OK not OK not OK MacOS 11.x OK OK OK OK not OK not OK iOS 14.x OK OK OK OK not OK not OK The reason is that the method
TTetheringNetworkManagerCommunicationThread.DoOnReceiveData
is never reached with this OS versions.This problem crops the usage of Tethering as the biggest part of MacOS/iOS devices are running with the newest OS-version. So Tethering is usable for Windows and Android only.
Do anybody knows a solution for this.
Best regards, Philipp
Activity
-
Yes, I've changed it in IdGlobalProtocols.TimeZoneBias. I've tested it only with Android but I'm very sure that it's fine for MacOS/iOS also.
I can test a new version of the Indy-implementation without huge effort, if this helps you. You have to send me only the pas-file to replace.
-
Hi Remy, it's
Result := -1 * (TTimeZone.Local.UtcOffset.TotalMinutes / 60 / 24);
-
The error occurs in IdGlobalProtocols.TimeZoneBias:
function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var T: Time_T; TV: TimeVal; UT: {$IFDEF USE_VCL_POSIX}tm{$ELSE}TUnixTime{$ENDIF}; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} {from http://edn.embarcadero.com/article/27890 } gettimeofday(TV, nil); T := TV.tv_sec; localtime_r({$IFNDEF USE_VCL_POSIX}@{$ENDIF}T, UT); // __tm_gmtoff is the bias in seconds from the UTC to the current time. // so I multiply by -1 to compensate for this. Result := (UT.{$IFNDEF USE_VCL_POSIX}__tm_gmtoff{$ELSE}tm_gmtoff{$ENDIF} / 60 / 60 / 24); {$ELSE} ...
If I replace this with the following it's fine:
function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var nowDt:TDateTime; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} nowDt:=NOW; Result := TTimeZone.Local.ToUniversalTime(nowDt)-nowDt; {$ELSE} ...
So it's fine for iOS and Android. For Android/FireOS there seems an additional issue with Delphi 10.3.3.
-
For me it's fine to compare with UTC time but the documentation of TIdTime says "DateTime is expressed in the timezone for the local computer".
And for Windows it's matching the documentation and for Android/iOS it's not matching the documentation. That's the point.In my case I need to know the difference between the local timestamp and the server timestamp. That's the reason to use TIdTime.
On Windows it's working fine, if the local time of computer A is 90 seconds ahead and of computer B it's 10 behind, I know that both computer's have a difference of 100 seconds and I have to keep this in mind for all synchronizations between both computers (it's a synchronization of video-play and it's should be insync with an accepted difference of +/-3 seconds.That's working as expected with my routine.
-
Hi,
I'm using TIdTime to synchronize the time for an online process but it's not working as expected:
Documentation TIdTime.DateTime:
- DateTime is a read-only TDateTime property that reflects the estimated current date and time according to a Time server.
- DateTime is expressed in the timezone for the local computer.procedure TicTrainerF.syncTime(); var idTime:TIdTime; dtLocal1,dtLocal2,dtServer:TDateTime; begin idTime:=TIdTime.create(nil); idTime.Host:='time.nist.gov'; dtLocal1:=NOW; dtServer:=idTime.dateTime; dtLocal2:=NOW; mlog.info('syncTime: '+DateToStr(dtLocal1,myFormatSettings)+'/'+DateToStr(dtLocal2,myFormatSettings)+' vs '+DateToStr(dtServer,myFormatSettings)); ...
It's fine for my windows-computers, so I can use it here.
1. But it's wrong for Android and iOS as the time is returned in UTC instead of the local time zone.
-> Question A: Is there a fixed rule for this so that it's always in UTC for this OS?
2. On my Amazon FireHD-10 tablet (FireOS/Android) I get something completly different.
-> Question B: Was is the reason for completly different results here?
incorrect (timezone):
---------------------
syncTime (Android): 2021-01-18 16:24:50.789-16:24:51.169 vs 2021-01-18 14:24:51.000
syncTime (Android): 2021-01-18 16:24:48.071-16:24:48.428 vs 2021-01-18 14:24:49.000
syncTime (iOS): 2021-01-18 16:24:49.658-16:24:49.996 vs 2021-01-18 14:24:50.000incorrect (at all):
-------------------
syncTime (FireOS/Android): 2021-01-18 16:24:48.606-16:24:49.028 vs 2021-01-18 14:40:02.000
correct:
--------
syncTime (Windows): 2021-01-18 16:24:47.612-16:24:48.359 vs 2021-01-18 16:24:48.000
syncTime (Windows): 2021-01-18 16:24:46.014-16:24:46.771 vs 2021-01-18 16:24:47.000
It's important for me that I can rely on the synchronization, else it's better to skip it and ask the user to take care of it.
Are there idea how to improve this synchronization?
Best regards, Philipp
-
QuoteI did end up using a USB Bluetooth dongle because the built-in Bluetooth on my 2012 Mac Mini didn't work
In this case I'm developing software for end consumer, so it's no solution if I have to use additional hardware or if I restrict the software to Sierra.
-
I can confirm, with Delphi 10.3.1 and MacOS Sierra (-> Xcode 9.2) the BLE implementation is up and running. So I don't have to use the old Delphi Version but have the problem that my clients have to use Sierra also (-> no use case for me).
-
I was able to use Delphi+BLE only in combination with MacOSX Sierra (or older) but not with High Sierra or Mojave -> this means it's not useable in my use case. If you know how I can use Delphi+BLE also with Mojave I'm extremly interested.
-
The next step is to downgrade my second MacBookAir to Sierra. But then I can use it internally but can't delivery it to end Consumer as I can't specify the OS-Version to use.
-
My software runs with all OS (Win32/Win64/MacOS/iOS/Android/Linux [fmxlinux]) but with MacOS the Delphi-BLE-implementation is not useable.
P.S.: With Linux BLE is also not useable but there isn't any BLE implementation until now, under MacOS is an error in the existing BLE implementation.- 1
-
I have now Delphi Berlin 10.1.2 installed, PA Server 18.0 and Xcode 9.4.1 but get still the exception "BluetoothDevice is not found or disconnected"
if I request "TBluetoothLEManager.startDiscovery" after I have set TBluetoothLE.enabled:=true successfully.
Any other tip?
-
Ok, to increase the Chance I vote for the following issues:
https://quality.embarcadero.com/browse/RSP-21029
https://quality.embarcadero.com/browse/RSP-22905 -
Hi,
is there any solution for this issue in meantime?
I use a MacBookAir 2018 with Mojave and XCode 10.1 with Delphi 10.3.1 and get the same error message if I want to use Bluetooth-LE on my MacBook Air.
Best regards, Philipp
TIdUDPListenerThread.UDPRead is not reached on MacOS 11 (but 10)
in RTL and Delphi Object Pascal
Posted
Hi,
I'm searching for the reason that TIdUDPListenerThread.UDPRead is not reached in my Tethering app if I run the app under MacOS 11. It's fine with MacOS 10.
The FBindind.Select(AcceptWait) is always return false on MacOS11.
How can I solve this?
Best regards, Philipp
TetheringDemo.zip